[Distutils] draft PEP: manylinux1

[Nick Coghlan]

On 22 January 2016 at 17:04, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
> On Thu, Jan 21, 2016 at 7:45 PM, Robert T. McGibbon <rmcgibbo at gmail.com> wrote:
>> On Thu, Jan 21, 2016 at 7:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> However, it does suggest a possible alternative approach to naming
>>> these compatibility subsets: what if the name of this particular
>>> platform compatibility tag was something like "linux-sciabi1", rather
>>> than "manylinux1"?
>>
>> That's an interesting idea, but I personally don't see the manylinux1 list
>> as particularly
>> "scientific". If anything, I'd call it "minimal".
>
> Yes, I agree, I don't think 'linux-sciabi1" would differentiate this
> from other ways of building wheels.  For example, I can't see why this
> wouldn't be a perfectly reasonable way to proceed for someone doing
> audio or video.   The difference that "manylinux" was designed to
> capture is the idea of having a single set of wheels for many versions
> of Linux, rather than wheels specific to particular distributions or
> packaged versions of external libraries.

Yeah, it was just an idea to potentially address MAL's concerns
regarding scope. However, I think the other replies to the thread have
adequately addressed that, and we can continue deferring the question
of scope increases to manylinux2 after seeing how far the current list
and "auditwheel repair" can get us.

The PEP should also be explicit that this does reintroduce the
bundling problem that distro unbundling policies were designed to
address, but:

1. In these days of automated continuous intregration & deployment
pipelines, publishing new versions and updating dependencies is easier
than it was when those policies were defined
2. Folks remain free to use "--no-binary" if they want to force local
builds rather than using pre-built wheel files
3. The popularity of container based deployment and "immutable
infrastructure" models involve substantial bundling at the application
layer anyway
4. This PEP doesn't rule out the idea of offering more targeted
binaries for particular Linux distributions

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia