On 16.02.2016 15:43, David Cournapeau wrote:
On Tue, Feb 16, 2016 at 11:05 AM, Matthias Klose <d...@ubuntu.com> wrote:
On 02.02.2016 02:35, Glyph Lefkowitz wrote:
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.
You may call this sour grapes, but in the light of people installing
these wheels to replace/upgrade system installed eggs, it becomes an
issue. It's fine to use such wheels in a virtual environment, however
people tell users to use these wheels to replace system installed packages,
distros will have a problem identifying issues.
FWIW, I often point out when people put "sudo" and "pip" in the same
sentence.
What about adding some language around this to the PEP ?
that's one thing. But maybe pip itself could error out on such a situation, and
maybe overriden with a non-default flag.
I know we had such an issue where pip accidentally modified system installed
files, maybe Barry still remembers the details ...
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.
I'm unsure how more specific and featureful distro tags will help, unless
you start building more than one binary version of a wheel. From a distro
point of view I only can discourage using such wheels outside a virtual
environment, and I would like to see a possibility to easily identify such
wheels, something like loading a binary kernel module is tainting the
kernel. This way distros can point users to the provider of such wheels.
This sounds like a good idea to me. Do you have a specific idea on how you
would like to see the feature work ?
Not really yet. lsmod shows you this information on demand for the running
kernel. So maybe you want to add such vendor information into the egg, or in
the compiled extension, and in the interpreter? Then give a warning when the
interpreter is called with a new option and the vendor informations don't match,
or even error out. Of course interested distros would have to backport such a
patch to older releases, because that's the target market for the pep.
Matthias
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
