[Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Vitaly Kruglikov]

On 22 June 2016 at 08:51, Nathaniel Smith  wrote:
> I believe the status is that there's general consensus that something like
> this would be useful, but there's no one who is currently actively working
> in it.

Thanks everyone for following up on my questions. This helps a lot. In 
particular, thank you for pointing me to manylinux1. 
https://www.python.org/dev/peps/pep-0513 appears to be incredibly well written, 
with excellent insights. I will likely adopt the manylinux1 approach.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Vitaly Kruglikov]

Thanks everyone for following up on my questions. This helps a lot. In 
particular, thank you for pointing me to manylinux1. 
https://www.python.org/dev/peps/pep-0513 appears to be incredibly well written, 
with excellent insights. I will likely adopt the manylinux1 approach.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Nick Coghlan]

On 22 June 2016 at 08:51, Nathaniel Smith  wrote:
> I believe the status is that there's general consensus that something like
> this would be useful, but there's no one who is currently actively working
> in it.

Checking https://wheels.galaxyproject.org/packages/ suggests that the
Galaxy Project folks did make some progress with it (scroll down to
the psycopg2 packages), so it may be worth pinging Nate Coraor
directly to see how far they got with the tooling support.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Noah Kantrowitz]

> On Jun 22, 2016, at 2:42 PM, Donald Stufft  wrote:
> 
> 
>> On Jun 22, 2016, at 5:38 PM, Glyph  wrote:
>> 
>> 
>>> On Jun 22, 2016, at 12:21, Nathaniel Smith  wrote:
>>> There are still use cases for distro-specific wheels, though -- some 
>>> examples include Raspbian wheels (manylinux1 is x86/x86-64 only), Alpine 
>>> Linux wheels (manylinux1 is glibc only), internal deploys that want to 
>>> build on Ubuntu 14.04 and deploy on 14.04 and don't need the hassle of 
>>> generating manylinux-style binaries but would like a more meaningful 
>>> platform tag than "linux", and for everyone who wants to extend wheel 
>>> metadata to allow dependencies on external distro packages then having 
>>> distro-specific wheels is probably a necessary first step.
>>> 
>> If we want to treat distros as first-class deployment targets I think being 
>> able to use their platform features in a way that's compatible with PyPI is 
>> an important next step.  However, wheel tags might be insufficient here; the 
>> main appeal of creating distro-specific wheels is being able to use 
>> distro-specific features, but those typically come along with specific 
>> package dependencies as well, and we don't have a way to express those yet.
> 
> I don’t think these two things need to be bound together. People can already 
> today depend on platform specific things just by not publishing wheels. 
> Adding these tags naturally follows that, where people would need to manually 
> install items from the OS before they used them. Adding some mechanism for 
> automating this would be a good, further addition, but I think they are 
> separately useful (and even more useful and powerful when combined).

I could see an argument for maybe building support into Pip but disallowing 
them on PyPI until we feel comfortable with the UX. That doesn't add much over 
existing private index support though.

--Noah



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Glyph]

> On Jun 22, 2016, at 14:42, Donald Stufft  wrote:
> 
> I don’t think these two things need to be bound together. People can already 
> today depend on platform specific things just by not publishing wheels. 
> Adding these tags naturally follows that, where people would need to manually 
> install items from the OS before they used them. Adding some mechanism for 
> automating this would be a good, further addition, but I think they are 
> separately useful (and even more useful and powerful when combined).

OK, fair point. I don't disagree with any of that. As long as everyone has a 
clear idea that this is part of a phased approach so the wheel tags should be 
ultimately upwards compatible with something that does dependencies, this all 
sounds pretty good (and an incremental approach with benefits at each stage is 
more likely to succeed anyhow).

-glyph___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Noah Kantrowitz]

> On Jun 22, 2016, at 2:42 PM, Donald Stufft  wrote:
> 
> 
>> On Jun 22, 2016, at 5:38 PM, Glyph  wrote:
>> 
>> 
>>> On Jun 22, 2016, at 12:21, Nathaniel Smith  wrote:
>>> There are still use cases for distro-specific wheels, though -- some 
>>> examples include Raspbian wheels (manylinux1 is x86/x86-64 only), Alpine 
>>> Linux wheels (manylinux1 is glibc only), internal deploys that want to 
>>> build on Ubuntu 14.04 and deploy on 14.04 and don't need the hassle of 
>>> generating manylinux-style binaries but would like a more meaningful 
>>> platform tag than "linux", and for everyone who wants to extend wheel 
>>> metadata to allow dependencies on external distro packages then having 
>>> distro-specific wheels is probably a necessary first step.
>>> 
>> If we want to treat distros as first-class deployment targets I think being 
>> able to use their platform features in a way that's compatible with PyPI is 
>> an important next step.  However, wheel tags might be insufficient here; the 
>> main appeal of creating distro-specific wheels is being able to use 
>> distro-specific features, but those typically come along with specific 
>> package dependencies as well, and we don't have a way to express those yet.
> 
> I don’t think these two things need to be bound together. People can already 
> today depend on platform specific things just by not publishing wheels. 
> Adding these tags naturally follows that, where people would need to manually 
> install items from the OS before they used them. Adding some mechanism for 
> automating this would be a good, further addition, but I think they are 
> separately useful (and even more useful and powerful when combined).

I could see an argument for maybe building support into Pip but disallowing 
them on PyPI until we feel comfortable with the UX. That doesn't add much over 
existing private index support though.

--Noah



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Robert Collins]

They're definitely separate; there's a draft PEP Tennessee and I
started at PyCon AU 2014 which would make a good basis for such an
effort.

-Rob

On 23 June 2016 at 09:42, Donald Stufft  wrote:
>
> On Jun 22, 2016, at 5:38 PM, Glyph  wrote:
>
>
> On Jun 22, 2016, at 12:21, Nathaniel Smith  wrote:
>
> There are still use cases for distro-specific wheels, though -- some
> examples include Raspbian wheels (manylinux1 is x86/x86-64 only), Alpine
> Linux wheels (manylinux1 is glibc only), internal deploys that want to build
> on Ubuntu 14.04 and deploy on 14.04 and don't need the hassle of generating
> manylinux-style binaries but would like a more meaningful platform tag than
> "linux", and for everyone who wants to extend wheel metadata to allow
> dependencies on external distro packages then having distro-specific wheels
> is probably a necessary first step.
>
> If we want to treat distros as first-class deployment targets I think being
> able to use their platform features in a way that's compatible with PyPI is
> an important next step.  However, wheel tags might be insufficient here; the
> main appeal of creating distro-specific wheels is being able to use
> distro-specific features, but those typically come along with specific
> package dependencies as well, and we don't have a way to express those yet.
>
>
> I don’t think these two things need to be bound together. People can already
> today depend on platform specific things just by not publishing wheels.
> Adding these tags naturally follows that, where people would need to
> manually install items from the OS before they used them. Adding some
> mechanism for automating this would be a good, further addition, but I think
> they are separately useful (and even more useful and powerful when
> combined).
>
>
> I think this is worthwhile to do, but figuring out a way to do it is
> probably going to take a lot of discussion.
>
> -glyph
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> —
> Donald Stufft
>
>
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Donald Stufft]

> On Jun 22, 2016, at 5:38 PM, Glyph  wrote:
> 
> 
>> On Jun 22, 2016, at 12:21, Nathaniel Smith > > wrote:
>> There are still use cases for distro-specific wheels, though -- some 
>> examples include Raspbian wheels (manylinux1 is x86/x86-64 only), Alpine 
>> Linux wheels (manylinux1 is glibc only), internal deploys that want to build 
>> on Ubuntu 14.04 and deploy on 14.04 and don't need the hassle of generating 
>> manylinux-style binaries but would like a more meaningful platform tag than 
>> "linux", and for everyone who wants to extend wheel metadata to allow 
>> dependencies on external distro packages then having distro-specific wheels 
>> is probably a necessary first step.
>> 
> 
> If we want to treat distros as first-class deployment targets I think being 
> able to use their platform features in a way that's compatible with PyPI is 
> an important next step.  However, wheel tags might be insufficient here; the 
> main appeal of creating distro-specific wheels is being able to use 
> distro-specific features, but those typically come along with specific 
> package dependencies as well, and we don't have a way to express those yet.

I don’t think these two things need to be bound together. People can already 
today depend on platform specific things just by not publishing wheels. Adding 
these tags naturally follows that, where people would need to manually install 
items from the OS before they used them. Adding some mechanism for automating 
this would be a good, further addition, but I think they are separately useful 
(and even more useful and powerful when combined).

> 
> I think this is worthwhile to do, but figuring out a way to do it is probably 
> going to take a lot of discussion.
> 
> -glyph
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig


—
Donald Stufft



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Glyph]

> On Jun 22, 2016, at 12:21, Nathaniel Smith  wrote:
> There are still use cases for distro-specific wheels, though -- some examples 
> include Raspbian wheels (manylinux1 is x86/x86-64 only), Alpine Linux wheels 
> (manylinux1 is glibc only), internal deploys that want to build on Ubuntu 
> 14.04 and deploy on 14.04 and don't need the hassle of generating 
> manylinux-style binaries but would like a more meaningful platform tag than 
> "linux", and for everyone who wants to extend wheel metadata to allow 
> dependencies on external distro packages then having distro-specific wheels 
> is probably a necessary first step.
> 

If we want to treat distros as first-class deployment targets I think being 
able to use their platform features in a way that's compatible with PyPI is an 
important next step.  However, wheel tags might be insufficient here; the main 
appeal of creating distro-specific wheels is being able to use distro-specific 
features, but those typically come along with specific package dependencies as 
well, and we don't have a way to express those yet.

I think this is worthwhile to do, but figuring out a way to do it is probably 
going to take a lot of discussion.

-glyph

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Nathaniel Smith]

There are still use cases for distro-specific wheels, though -- some
examples include Raspbian wheels (manylinux1 is x86/x86-64 only), Alpine
Linux wheels (manylinux1 is glibc only), internal deploys that want to
build on Ubuntu 14.04 and deploy on 14.04 and don't need the hassle of
generating manylinux-style binaries but would like a more meaningful
platform tag than "linux", and for everyone who wants to extend wheel
metadata to allow dependencies on external distro packages then having
distro-specific wheels is probably a necessary first step.

-n
On Jun 22, 2016 09:49, "Noah Kantrowitz"  wrote:

Manylinux has mostly replaced it as that covers the platforms 99% of people
worry about. The tooling for manylinux is more complex than this would have
been, but sunk cost etc etc and now that we have it might as well save
everyone some headache.

--Noah

> On Jun 22, 2016, at 8:51 AM, Nathaniel Smith  wrote:
>
> I believe the status is that there's general consensus that something
like this would be useful, but there's no one who is currently actively
working in it.
>
> On Jun 22, 2016 5:53 AM, "Vitaly Kruglikov" 
wrote:
> There have been no updates in over a year. Has this effort died, or
transitioned to another medium? Thx
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Noah Kantrowitz]

Manylinux has mostly replaced it as that covers the platforms 99% of people 
worry about. The tooling for manylinux is more complex than this would have 
been, but sunk cost etc etc and now that we have it might as well save everyone 
some headache.

--Noah

> On Jun 22, 2016, at 8:51 AM, Nathaniel Smith  wrote:
> 
> I believe the status is that there's general consensus that something like 
> this would be useful, but there's no one who is currently actively working in 
> it.
> 
> On Jun 22, 2016 5:53 AM, "Vitaly Kruglikov"  wrote:
> There have been no updates in over a year. Has this effort died, or 
> transitioned to another medium? Thx
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Nathaniel Smith]

I believe the status is that there's general consensus that something like
this would be useful, but there's no one who is currently actively working
in it.
On Jun 22, 2016 5:53 AM, "Vitaly Kruglikov"  wrote:

There have been no updates in over a year. Has this effort died, or
transitioned to another medium? Thx

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

[Vitaly Kruglikov]

There have been no updates in over a year. Has this effort died, or 
transitioned to another medium? Thx
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Nick Coghlan]

On 1 December 2014 at 11:41, Marcus Smith qwc...@gmail.com wrote:
 +1 to the idea in general.
 Would this be an *edit* to PEP425/427/Wheel-1.0  OR new peps, and a new
 wheel version?

I'm currently thinking no change to the wheel spec, but potentially a
PEP to define a standard way to override and/or supplement the default
compatibility tags.

 As someone using cent6 daily (with no os-release file), I'm greedy for
 another fallback technique, but the simplicity of just using os-release
 makes sense.
 Could a published linux_x86_64_fedora_20 wheel ever become broken just due
 to normal yum update activity on fedora_20?  When? Why?

It's technically possible to get an ABI break mid-cycle on Fedora, as
it doesn't have the same level of restrictions against rebasing
components that RHEL/CentOS do. Actually encountering an ABI break
would still be pretty unlucky though.

However, I realised my original idea doesn't quite work, since
derivative distros may strive to be ABI compatible with their
upstreams. While /etc/os-release sort of supports that concept via
ID_LIKE, it's entirely vague about what that actually means, and the
ID_LIKE distro references aren't versioned at all. There's also the
fact that at least RHEL/CentOS aim to remain ABI compatible for the
duration of an entire release series, so including the full version of
/etc/os-release would overspecify things.

That got me back to the idea of being able to customise the platform
tag which various folks have brought up in the past. At that point,
the definition in PEP 425 would become the specification for the
*default* platform tag, and we'd look at adding ways to override it
both when building wheels and when installing them.

The main possibility I thought of there was to come up with a
convention for overriding the platform tag at the *virtual
environment* level. Then bdist_wheel, pip and other projects could
check for the override before falling back to the default definition
from PEP 425. If we designed the mechanisms correctly, it could
potentially also be used to address the no SOABI details problem on
Python 2.7.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Marcus Smith]

+1 to the idea in general.
Would this be an *edit* to PEP425/427/Wheel-1.0  OR new peps, and a new
wheel version?
As someone using cent6 daily (with no os-release file), I'm greedy for
another fallback technique, but the simplicity of just using os-release
makes sense.
Could a published linux_x86_64_fedora_20 wheel ever become broken just
due to normal yum update activity on fedora_20?  When? Why?

On Thu, Nov 27, 2014 at 10:03 PM, Nick Coghlan ncogh...@gmail.com wrote:

 We've discussed the idea of changing the wheel file naming scheme to
 deal with Linux previously, but never put together a concrete
 proposal.

 The closest we've got is the idea of allowing the platform tag to be
 customised in pip and perhaps bdist_wheel, and while that's good from
 an enabling experimentation perspective, it may be overkill if the
 primary goal is just to better support handling of Linux distros.

 For starters, here's the current definition of the platform tag in PEP 425:

 =
 The platform tag is simply distutils.util.get_platform() with all
 hyphens - and periods . replaced with underscore _ .

 * win32
 * linux_i386
 * linux_x86_64
 =

 Here's my proposed change:

 =
 The default platform tag is distutils.util.get_platform() with all
 hyphens - and periods . replaced with underscore _ . If
 /etc/os-release [N] exists on the system, then the values in the 'ID'
 and 'VERSION_ID' fields are read, all hyphens - and periods . replaced
 with underscore _ , and the results appended to the default tag after
 a separating underscore.

 Examples:

 * win32
 * macosx_10_6_intel
 * linux_x86_64_fedora_20
 * linux_x86_64_rhel_7_0
 * linux_x86_64_debian_7_0
 * linux_x86_64_ubuntu_14_04
 =

 The [N] reference would then be a reference to
 http://www.freedesktop.org/software/systemd/man/os-release.html for
 the definition of the format of os-release. (Note that while the
 format originated with systemd, plenty of distros have also started
 providing it regardless of which init system they use)

 Now, this slightly overspecifies on the *consumer* side. A binary
 wheel that works on rhel_7_0 for example, should almost certainly
 work on rhel_7_1. However, that can be addressed on the tooling side
 (e.g. permitting the specification of additional compatible
 platforms when invoking pip), rather than needing to be in the
 specification.

 This also won't help with older Linux distros that don't offer
 /etc/os-release, but I'm OK with that - those can just continue to
 show up as linux_x86_64, and PyPI can continue to disallow those
 uploads.

 Cheers,
 Nick.

 --
 Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Nick Coghlan]

On 29 November 2014 at 01:51, Antoine Pitrou solip...@pitrou.net wrote:
 On Sat, 29 Nov 2014 01:27:44 +1000
 Nick Coghlan ncogh...@gmail.com wrote:
 
  Is this not going to be a slippery slope?

 Only if folks publish Linux binaries themselves, and that's still a
 bad idea (for the same reason publishing distro binaries is already a
 rare thing for people to do).

 Well, let's not make this a matter of ideology. Everyone knows it's a
 bad idea to publish binaries, yet it's often better than nothing,
 especially if the software is tedious to compile.

It's not a matter of ideology, but a matter of practicality. Debian
stable, RHEL/CentOS, Ubuntu LTS, SLES - distros like these move slow
enough (and have strong enough ABI compatibility guarantees) to be
practical for ISVs to target with prebuilt binaries. Beyond that, the
rate of development and breadth of target environments in the Linux
world tends to make providing prebuilt binaries in *any* format
difficult (unless you statically link everything you need, which works
fine until you decide you want a particular package to depend on
binaries provided by another one by linking to them dynamically).

Regardless of target environment, though, being able to prebuild wheel
files in a way that clearly indicates the platform restricted nature
of the end result is a useful tool for system integrators. That
benefit applies regardless of whether the builds are happening in the
context of Linux distro development, or in the context of maintaining
a particular set of infrastructure services.

  How many binary packages will package authors have to provide to cover
  people's needs? Windows + OS X + Linux multiplied by 32 / 64 multiplied
  by three or four Python versions is already a lot of binaries to
  build...

 I'd still advise against folks posting Linux wheels on PyPI, just as
 they tend not to post RPM or deb files. This is so we can provide
 wheels at the distro level (or build them internally) without creating
 vast amounts of confusion.

 So do we (software authors) have to wait for that mythical we who are
 going to build binaries in time for our packages?

If the compatibility tagging issue can be resolved, I don't think
there should be any restrictions against uploading Linux wheels that
avoid the generic Linux platform tags. I just doubt it will make sense
for most developers to worry about it, just as most of them don't
worry about providing RPMs or Debian packages.

 Case in point: can I ask you (the mythical we) to build packages for
 all major distros (including supported LTS releases), and the four most
 recent Python versions, of the following piece of software:
 https://github.com/numba/llvmlite

No, that would be a service provided by the as yet hypothetical PyPI
build farm. If/when that happens, it will need to have a way of
tagging Linux wheels appropriately, though.

Nearer term (and what prompted me to start this thread), the Fedora
Environments  Stacks working group is investigating providing
prebuilt wheel files for the Fedora ecosystem, and potentially for
EPEL as well (see
https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement
for the broader context of that effort). For other ecosystems, you'll
have to ask participants in those ecosystems.

 This isn't really about that - it's about having a way to
 tackle it at the distro level, without introducing significant
 potential for confusion on end user systems

 I'm not sure I understand: distros provide their own packages, they
 don't (shouldn't) blindly pull binary wheels from PyPI. Why would they
 depend on the wheel tagging format?

We don't plan to blindly pull anything from PyPI - we're looking at
the feasibility of publishing already reviewed software in ecosystem
native formats (with the two pilot projects focusing on Java JAR files
and Python wheel files).

When I last mentioned that idea here, Marcus pointed out that doing
that with the generic linux_x86_64 compatibility tag on the wheel
filenames would be problematic, as there'd be nothing preventing
anyone from pulling them down onto inappropriate systems, with no
obvious trace of the Fedora or EPEL specific assumptions that went
into building them.

While that's a valid concern, I also don't want to go invent our own
custom compatibility tagging convention just for Fedora  EPEL, but
rather work within the limits of what upstream Python packaging
natively supports. At the moment there is no such tagging system,
which is why I'm interested in pursuing improvements to the definition
of the platform tag.

However, after thinking further about the situation with EPEL (where
we'd likely want a single set of wheel files to cover not only an
entire major release series, but also downstream RHEL derivatives like
CentOS), the possibility of sharing wheel files between the Fedora 
Software Collections Python builds, and the point Matthias raised
about the limitations of the current platform tag when it comes to

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Antoine Pitrou]

On Sun, 30 Nov 2014 01:47:16 +1000
Nick Coghlan ncogh...@gmail.com wrote:
 On 29 November 2014 at 01:51, Antoine Pitrou solip...@pitrou.net wrote:
  On Sat, 29 Nov 2014 01:27:44 +1000
  Nick Coghlan ncogh...@gmail.com wrote:
  
   Is this not going to be a slippery slope?
 
  Only if folks publish Linux binaries themselves, and that's still a
  bad idea (for the same reason publishing distro binaries is already a
  rare thing for people to do).
 
  Well, let's not make this a matter of ideology. Everyone knows it's a
  bad idea to publish binaries, yet it's often better than nothing,
  especially if the software is tedious to compile.
 
 It's not a matter of ideology, but a matter of practicality. Debian
 stable, RHEL/CentOS, Ubuntu LTS, SLES - distros like these move slow
 enough (and have strong enough ABI compatibility guarantees) to be
 practical for ISVs to target with prebuilt binaries.

It seems we disagree on the notion of practicality :-)

For me practicality means being able to build a single binary package
for all recent Linux distros in a best effort approach. Building a
different package for each distro version is far from practical for any
reasonable-sized project (i.e. not something sponsored by a
1000+-employee entity, with a dedicated build team and infrastructure).

  Case in point: can I ask you (the mythical we) to build packages for
  all major distros (including supported LTS releases), and the four most
  recent Python versions, of the following piece of software:
  https://github.com/numba/llvmlite
 
 No, that would be a service provided by the as yet hypothetical PyPI
 build farm. If/when that happens, it will need to have a way of
 tagging Linux wheels appropriately, though.

If/when that happens is not reassuring, especially in the light of
how many pie-in-the-sky improvements in the packaging ecosystems have
turned out :-/

(at Continuum we have started offering such a service, but it's
generic Linux: http://docs.binstar.org/build-config.html#BuildMatrix)

 Nearer term (and what prompted me to start this thread), the Fedora
 Environments  Stacks working group is investigating providing
 prebuilt wheel files for the Fedora ecosystem, and potentially for
 EPEL as well (see
 https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement
 for the broader context of that effort). For other ecosystems, you'll
 have to ask participants in those ecosystems.

That's asking software authors to complicate and slow down their
development process a lot. Also, there's no guarantee that Fedora or
Ubuntu or whatever would actually *accept* to help us, right?

  I'm not sure I understand: distros provide their own packages, they
  don't (shouldn't) blindly pull binary wheels from PyPI. Why would they
  depend on the wheel tagging format?
 
 We don't plan to blindly pull anything from PyPI - we're looking at
 the feasibility of publishing already reviewed software in ecosystem
 native formats (with the two pilot projects focusing on Java JAR files
 and Python wheel files).
 
 When I last mentioned that idea here, Marcus pointed out that doing
 that with the generic linux_x86_64 compatibility tag on the wheel
 filenames would be problematic, as there'd be nothing preventing
 anyone from pulling them down onto inappropriate systems, with no
 obvious trace of the Fedora or EPEL specific assumptions that went
 into building them.

Uh, there's a lot of hidden knowledge required to understand those
two paragraphs that I don't master. I don't know what inappropriate
systems are, what are reviewed software, etc. ;-)

Also I don't understand why you're not recompiling as you would
normally do.

 While that's a valid concern, I also don't want to go invent our own
 custom compatibility tagging convention just for Fedora  EPEL, but
 rather work within the limits of what upstream Python packaging
 natively supports.

Well, *allowing* distro tags in the platform tag is certainly ok. What
I'm afraid of is if that's made mandatory.

 Consider if the following could be included in the pyvenv.cfg file
 in a virtual environment:
 
 [compatibility]
 python=cp27,cp2,py2
 abi=cp27mu
 platform=linux_x86_64_epel_6
 
 Or for a Python 3 virtual environment:
 
 [compatibility]
 python=cp34,cp3,py3
 abi=cp34m,abi3
 platform=linux_x86_64_epel_6
 
 If present, these pyvenv.cfg settings would override the normal PEP
 425 compatibility tag calculations (I'm OK with the idea of *needing*
 to be in a virtual environment to gain the power to configure these
 tags).

As long as it's on an opt-in basis, it certainly sounds ok.

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Nick Coghlan]

On 30 November 2014 at 02:10, Antoine Pitrou solip...@pitrou.net wrote:
 On Sun, 30 Nov 2014 01:47:16 +1000
 Nick Coghlan ncogh...@gmail.com wrote:
 On 29 November 2014 at 01:51, Antoine Pitrou solip...@pitrou.net wrote:
  On Sat, 29 Nov 2014 01:27:44 +1000
  Nick Coghlan ncogh...@gmail.com wrote:
  
   Is this not going to be a slippery slope?
 
  Only if folks publish Linux binaries themselves, and that's still a
  bad idea (for the same reason publishing distro binaries is already a
  rare thing for people to do).
 
  Well, let's not make this a matter of ideology. Everyone knows it's a
  bad idea to publish binaries, yet it's often better than nothing,
  especially if the software is tedious to compile.

 It's not a matter of ideology, but a matter of practicality. Debian
 stable, RHEL/CentOS, Ubuntu LTS, SLES - distros like these move slow
 enough (and have strong enough ABI compatibility guarantees) to be
 practical for ISVs to target with prebuilt binaries.

 It seems we disagree on the notion of practicality :-)

Note I said ISVs there - folks that actually make money from
targetting those platforms. I don't think providing integrated Linux
binaries is currently practical at all for open source projects (note
that even CPython just provides a tarball upstream, with the builds
handled directly by the distros).

 For me practicality means being able to build a single binary package
 for all recent Linux distros in a best effort approach.

That isn't realistically possible for anything that isn't completely
statically linked, as distro level choices of build options vary too
much.

We could technically allow statically linked binaries on PyPI by
dropping the restriction against generic Linux wheel files, but I'm
wary of that in the absence of an automated server side scan for
dynamically linked binaries.

Many users (quite reasonably, if they're primarily Python developers)
have problems working through build failures when attempting to
install non-Python extensions from source. Such build failures are
usually models of clarity compared to diagnosing dynamic linking
failures.

 Building a
 different package for each distro version is far from practical for any
 reasonable-sized project (i.e. not something sponsored by a
 1000+-employee entity, with a dedicated build team and infrastructure).

This is why I'm saying people *shouldn't* try to provide prebuilt
Linux binaries in the general case: it's simply not practical. Hence
the rise of higher level, more self-contained formats like Docker, as
well as the fact that I'm not even trying to solve the any Linux
problem myself, but going after the vastly simpler problem of
targeting the ecosystem I need to target (but hopefully in a
sufficiently general purpose way that other ecosystems can adopt the
same model if they so choose).

  Case in point: can I ask you (the mythical we) to build packages for
  all major distros (including supported LTS releases), and the four most
  recent Python versions, of the following piece of software:
  https://github.com/numba/llvmlite

 No, that would be a service provided by the as yet hypothetical PyPI
 build farm. If/when that happens, it will need to have a way of
 tagging Linux wheels appropriately, though.

 If/when that happens is not reassuring, especially in the light of
 how many pie-in-the-sky improvements in the packaging ecosystems have
 turned out :-/

Nobody is currently offering to provide paid staff to work on it, so
it won't happen until it gets to the top of volunteers' personal
priority lists.

 (at Continuum we have started offering such a service, but it's
 generic Linux: http://docs.binstar.org/build-config.html#BuildMatrix)

Yes, Continuum avoided the distro ABI compatibility problem by
defining its own ABI. It's exactly the same model I'm proposing - in
the general case, you can't take Continuum built packages, and use
them with Fedora/Debian/etc built dynamically linked dependencies.
Same with my suggestion - it's about labelling the compatibility
requirements, rather than trying to avoid them by statically linking
everything.

 Nearer term (and what prompted me to start this thread), the Fedora
 Environments  Stacks working group is investigating providing
 prebuilt wheel files for the Fedora ecosystem, and potentially for
 EPEL as well (see
 https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement
 for the broader context of that effort). For other ecosystems, you'll
 have to ask participants in those ecosystems.

 That's asking software authors to complicate and slow down their
 development process a lot.

If the distro level service doesn't benefit them, there's no reason
for software authors to use it. This is about adding a new option for
consuming software, not taking anything away.

In my case, I won't deploy something until it's been through at least
a basic licensing review, and if we're doing that work anyway, I may
as well see if we can find a way to do it 

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/29/2014 11:10 AM, Antoine Pitrou wrote:

 For me practicality means being able to build a single binary package 
 for all recent Linux distros in a best effort approach.

I can't imagine finding any such binary useful (assuming a
none-pure-Python project):  the chance that it *might* blow up makes it
easier just to create my own from the sdist.  Such binaries would tend to
bitrot, even if they were OK for the supported set of distros at the
time they were made.

How can such wheels be feasible, when cross-distro RPMs / .debs are
clearly not (in the general sense)?



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlR6BMUACgkQ+gerLs4ltQ70sgCeJ8BmRVDOhEzJ4I70eGWQCLn4
l0cAoJwoHcC26M/t5mhLXgJl4IrugDcV
=G5zd
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Antoine Pitrou]

On Sun, 30 Nov 2014 03:02:57 +1000
Nick Coghlan ncogh...@gmail.com wrote:
 Many users (quite reasonably, if they're primarily Python developers)
 have problems working through build failures when attempting to
 install non-Python extensions from source. Such build failures are
 usually models of clarity compared to diagnosing dynamic linking
 failures.

However, installing a binary doesn't imply a potential longish building
step, or the installation of many build dependencies. LLVM can take 20
minutes to compile on a modern quad-core x86. I've been told it takes
several hours on a Cortex A8 platform... By comparison, the failure of
loading a precompiled dynamic library is instantaneous.

And I don't think build failures are understandable by many users. You
need to be a seasoned C developer for that.

  (at Continuum we have started offering such a service, but it's
  generic Linux: http://docs.binstar.org/build-config.html#BuildMatrix)
 
 Yes, Continuum avoided the distro ABI compatibility problem by
 defining its own ABI.

Not exactly. Some ABI problems - for example the glibc-related ones -
are still here. Conda and binstar-build are still a best effort (on the
GNU/Linux side, that is), not an ideal solution.

  Well, *allowing* distro tags in the platform tag is certainly ok. What
  I'm afraid of is if that's made mandatory.
 
 OK, that makes more sense. Yes, I agree we need to keep the ability to
 say this is a prebuilt, self-contained, binary wheel that should run
 on any Linux system because it doesn't link to any system binaries.
 Chalk it up as yet another reason that the specific proposal I started
 the thread with wouldn't actually work :)

Great!

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Antoine Pitrou]

On Fri, 28 Nov 2014 16:03:59 +1000
Nick Coghlan ncogh...@gmail.com wrote:
 Here's my proposed change:
 
 =
 The default platform tag is distutils.util.get_platform() with all
 hyphens - and periods . replaced with underscore _ . If
 /etc/os-release [N] exists on the system, then the values in the 'ID'
 and 'VERSION_ID' fields are read, all hyphens - and periods . replaced
 with underscore _ , and the results appended to the default tag after
 a separating underscore.
 
 Examples:
 
 * win32
 * macosx_10_6_intel
 * linux_x86_64_fedora_20
 * linux_x86_64_rhel_7_0
 * linux_x86_64_debian_7_0
 * linux_x86_64_ubuntu_14_04

Is this not going to be a slippery slope?

 Now, this slightly overspecifies on the *consumer* side. A binary
 wheel that works on rhel_7_0 for example, should almost certainly
 work on rhel_7_1. However, that can be addressed on the tooling side
 (e.g. permitting the specification of additional compatible
 platforms when invoking pip), rather than needing to be in the
 specification.

How about those lesser known distributions (e.g. Linux Mint or Mageia)?
How many binary packages will package authors have to provide to cover
people's needs? Windows + OS X + Linux multiplied by 32 / 64 multiplied
by three or four Python versions is already a lot of binaries to
build...

While this would be a good technical solution, I think it's socially
disastrous.

Of course, you may point out that it has its roots in the failure of the
GNU/Linux ecosystem to provide real binary compatibility. It's stunning
that under Windows you can build a Windows XP-compatible shared library
with a recent MSVC just by turning a switch in the options...

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Marius Gedminas]

On Fri, Nov 28, 2014 at 04:03:59PM +1000, Nick Coghlan wrote:
 Here's my proposed change:
 
 =
 The default platform tag is distutils.util.get_platform() with all
 hyphens - and periods . replaced with underscore _ . If
 /etc/os-release [N] exists on the system, then the values in the 'ID'
 and 'VERSION_ID' fields are read, all hyphens - and periods . replaced
 with underscore _ , and the results appended to the default tag after
 a separating underscore.
 
 Examples:
 
 * win32
 * macosx_10_6_intel
 * linux_x86_64_fedora_20
 * linux_x86_64_rhel_7_0
 * linux_x86_64_debian_7_0
 * linux_x86_64_ubuntu_14_04
 =
 
 The [N] reference would then be a reference to
 http://www.freedesktop.org/software/systemd/man/os-release.html for
 the definition of the format of os-release. (Note that while the
 format originated with systemd, plenty of distros have also started
 providing it regardless of which init system they use)
...
 This also won't help with older Linux distros that don't offer
 /etc/os-release, but I'm OK with that - those can just continue to
 show up as linux_x86_64, and PyPI can continue to disallow those
 uploads.

I was curious about what older distros meant in the context of Ubuntu,
so I looked it up:  /etc/os-release exists in Ubuntu 12.04 LTS (and
newer) but didn't exist in Ubuntu 10.04 LTS.

Support for Ubuntu 10.04 LTS ends in April 2015.

Marius Gedminas
-- 
Give a man a computer program and you give him a headache, but teach him to
program computers and you give him the power to create headaches for others for
the rest of his life...
-- R. B. Forest


signature.asc
Description: Digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Nick Coghlan]

On 28 November 2014 at 18:19, Antoine Pitrou solip...@pitrou.net wrote:
 On Fri, 28 Nov 2014 16:03:59 +1000
 Nick Coghlan ncogh...@gmail.com wrote:
 Here's my proposed change:

 =
 The default platform tag is distutils.util.get_platform() with all
 hyphens - and periods . replaced with underscore _ . If
 /etc/os-release [N] exists on the system, then the values in the 'ID'
 and 'VERSION_ID' fields are read, all hyphens - and periods . replaced
 with underscore _ , and the results appended to the default tag after
 a separating underscore.

 Examples:

 * win32
 * macosx_10_6_intel
 * linux_x86_64_fedora_20
 * linux_x86_64_rhel_7_0
 * linux_x86_64_debian_7_0
 * linux_x86_64_ubuntu_14_04

 Is this not going to be a slippery slope?

Only if folks publish Linux binaries themselves, and that's still a
bad idea (for the same reason publishing distro binaries is already a
rare thing for people to do).

 Now, this slightly overspecifies on the *consumer* side. A binary
 wheel that works on rhel_7_0 for example, should almost certainly
 work on rhel_7_1. However, that can be addressed on the tooling side
 (e.g. permitting the specification of additional compatible
 platforms when invoking pip), rather than needing to be in the
 specification.

 How about those lesser known distributions (e.g. Linux Mint or Mageia)?

They tend to publish /etc/os-release as well these days, and there's
actually a mechanism built into that for clients to flag other distros
to try.

 How many binary packages will package authors have to provide to cover
 people's needs? Windows + OS X + Linux multiplied by 32 / 64 multiplied
 by three or four Python versions is already a lot of binaries to
 build...

I'd still advise against folks posting Linux wheels on PyPI, just as
they tend not to post RPM or deb files. This is so we can provide
wheels at the distro level (or build them internally) without creating
vast amounts of confusion.

 While this would be a good technical solution, I think it's socially
 disastrous.

Only if you're expecting folks to regularly publish their own wheels
to PyPI. This isn't really about that - it's about having a way to
tackle it at the distro level, without introducing significant
potential for confusion on end user systems
(https://fedoraproject.org/wiki/Env_and_Stacks/Projects/LanguageSpecificRepositories
describes the Fedora side of our current work in this area)

 Of course, you may point out that it has its roots in the failure of the
 GNU/Linux ecosystem to provide real binary compatibility. It's stunning
 that under Windows you can build a Windows XP-compatible shared library
 with a recent MSVC just by turning a switch in the options...

The difference isn't really that surprising - both Microsoft and Apple
have relied heavily on intellectual monopoly laws to retain control of
their ecosystems. You can do a lot to constrain the choices of others
when you have the full weight of the US government and copyright
industry behind you.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Nick Coghlan]

On 29 November 2014 at 01:31, Matthias Klose d...@ubuntu.com wrote:
 On 11/28/2014 07:03 AM, Nick Coghlan wrote:

 We've discussed the idea of changing the wheel file naming scheme to
 deal with Linux previously, but never put together a concrete
 proposal.

 The closest we've got is the idea of allowing the platform tag to be
 customised in pip and perhaps bdist_wheel, and while that's good from
 an enabling experimentation perspective, it may be overkill if the
 primary goal is just to better support handling of Linux distros.

 For starters, here's the current definition of the platform tag in PEP
 425:

 hmm, maybe you repeat the rationale here for starters?

To be able to publish wheel files for a particular ecosystem, without
causing confusion if those wheel files somehow end up in an unsuitable
environment (e.g. a Fedora specific wheel ending up on a Debian
machine).

 =
 The platform tag is simply distutils.util.get_platform() with all
 hyphens - and periods . replaced with underscore _ .

 * win32
 * linux_i386
 * linux_x86_64
 =


 this is already wrong for ARM32 soft-float and hard-float, and
 x86_64-linux-gnu and x86_64-linux-gnux32.  If something is changed, then
 please change that as well, maybe using something already defined like the
 multiarch triplet.

I'm open to completely redefining this in a distutils independent way,
but it will need someone to define the precise algorithm. For the
cases I'm personally worried about (i.e. Fedora  EPEL), the existing
information extraction from os.uname() should be adequate.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Antoine Pitrou]

On Sat, 29 Nov 2014 01:27:44 +1000
Nick Coghlan ncogh...@gmail.com wrote:
 
  Is this not going to be a slippery slope?
 
 Only if folks publish Linux binaries themselves, and that's still a
 bad idea (for the same reason publishing distro binaries is already a
 rare thing for people to do).

Well, let's not make this a matter of ideology. Everyone knows it's a
bad idea to publish binaries, yet it's often better than nothing,
especially if the software is tedious to compile.

  How many binary packages will package authors have to provide to cover
  people's needs? Windows + OS X + Linux multiplied by 32 / 64 multiplied
  by three or four Python versions is already a lot of binaries to
  build...
 
 I'd still advise against folks posting Linux wheels on PyPI, just as
 they tend not to post RPM or deb files. This is so we can provide
 wheels at the distro level (or build them internally) without creating
 vast amounts of confusion.

So do we (software authors) have to wait for that mythical we who are
going to build binaries in time for our packages?

Case in point: can I ask you (the mythical we) to build packages for
all major distros (including supported LTS releases), and the four most
recent Python versions, of the following piece of software:
https://github.com/numba/llvmlite

:-)

 This isn't really about that - it's about having a way to
 tackle it at the distro level, without introducing significant
 potential for confusion on end user systems

I'm not sure I understand: distros provide their own packages, they
don't (shouldn't) blindly pull binary wheels from PyPI. Why would they
depend on the wheel tagging format?

 The difference isn't really that surprising - both Microsoft and Apple
 have relied heavily on intellectual monopoly laws to retain control of
 their ecosystems. You can do a lot to constrain the choices of others
 when you have the full weight of the US government and copyright
 industry behind you.

That discussion is a bit off-topic, but I don't think it has anything
to do with copyright (and from I've seen in python-dev discussions,
I'm not sure Apple is a good example).

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Nick Coghlan]

We've discussed the idea of changing the wheel file naming scheme to
deal with Linux previously, but never put together a concrete
proposal.

The closest we've got is the idea of allowing the platform tag to be
customised in pip and perhaps bdist_wheel, and while that's good from
an enabling experimentation perspective, it may be overkill if the
primary goal is just to better support handling of Linux distros.

For starters, here's the current definition of the platform tag in PEP 425:

=
The platform tag is simply distutils.util.get_platform() with all
hyphens - and periods . replaced with underscore _ .

* win32
* linux_i386
* linux_x86_64
=

Here's my proposed change:

=
The default platform tag is distutils.util.get_platform() with all
hyphens - and periods . replaced with underscore _ . If
/etc/os-release [N] exists on the system, then the values in the 'ID'
and 'VERSION_ID' fields are read, all hyphens - and periods . replaced
with underscore _ , and the results appended to the default tag after
a separating underscore.

Examples:

* win32
* macosx_10_6_intel
* linux_x86_64_fedora_20
* linux_x86_64_rhel_7_0
* linux_x86_64_debian_7_0
* linux_x86_64_ubuntu_14_04
=

The [N] reference would then be a reference to
http://www.freedesktop.org/software/systemd/man/os-release.html for
the definition of the format of os-release. (Note that while the
format originated with systemd, plenty of distros have also started
providing it regardless of which init system they use)

Now, this slightly overspecifies on the *consumer* side. A binary
wheel that works on rhel_7_0 for example, should almost certainly
work on rhel_7_1. However, that can be addressed on the tooling side
(e.g. permitting the specification of additional compatible
platforms when invoking pip), rather than needing to be in the
specification.

This also won't help with older Linux distros that don't offer
/etc/os-release, but I'm OK with that - those can just continue to
show up as linux_x86_64, and PyPI can continue to disallow those
uploads.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig