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
