> On Feb 1, 2016, at 3:37 PM, Matthias Klose <d...@ubuntu.com> wrote:
> 
> On 30.01.2016 00:29, Nathaniel Smith wrote:
>> Hi all,
>> 
>> I think this is ready for pronouncement now -- thanks to everyone for
>> all their feedback over the last few weeks!
> 
> I don't think so.  I am biased because I'm the maintainer for Python in 
> Debian/Ubuntu.  So I would like to have some feedback from maintainers of 
> Python in other Linux distributions (Nick, no, you're not one of these).

Possibly, but it would be very helpful for such maintainers to limit their 
critique to "in what scenarios will this fail for users" and not have the whole 
peanut gallery chiming in with "well on _my_ platform we would have done it 
_this_ way".

I respect what you've done for Debian and Ubuntu, Matthias, and I use the heck 
out of that work, but honestly this whole message just comes across as sour 
grapes that someone didn't pick a super-old Debian instead of a super-old Red 
Hat.  I don't think it's promoting any progress.

> The proposal just takes some environment and declares that as a standard.  So 
> everybody wanting to supply these wheels basically has to use this 
> environment.

There's already been lots of discussion about how this environment is a lowest 
common denominator.  Many other similar environments could _also_ be lowest 
common denominator.

> Without giving any details, without giving any advise how to produce such 
> wheels in other environments. Without giving any hints how such wheels may be 
> broken with newer environments.

They won't be.  That's the whole point.

> Without mentioning this is am64/i386 only.

Wheels already have an architecture tag, separate from the platform tag, so 
this being "am64/i386" is irrelevant.

> There might be more. Pretty please be specific about your environment.  Have 
> a look how the LSB specifies requirements on the runtime environment ... and 
> then ask yourself why the lsb doesn't have any real value.


In the future, more specific and featureful distro tags sound like a good idea. 
 But could we please stop making the default position on distutils-sig "this 
doesn't cater to my one specific environment in the most optimal possible way, 
so let's give up on progress entirely"?  This is a good proposal that addresses 
environment portability and gives Python a substantially better build-artifact 
story than it currently has, in the environment most desperately needing one 
(server-side linux).  Could it be better?  Of course.  It could be lots better. 
 There are lots of use-cases for dynamically linked wheels and fancy new 
platform library features in newer linuxes.  But that can all come later, and 
none of it needs to have an impact on this specific proposal, right now.

-glyph

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

Reply via email to