[Python-Dev] Status of packaging in 3.3

Oscar Benjamin oscar.j.benjamin at gmail.com
Thu Jun 21 14:07:58 CEST 2012


On 21 June 2012 12:48, Chris McDonough <chrism at plope.com> wrote:

> On 06/21/2012 04:45 AM, Nick Coghlan wrote:
>
>> On Thu, Jun 21, 2012 at 2:44 PM, Chris McDonough<chrism at plope.com>
>>  wrote:
>>
>>> All of these are really pretty minor issues compared with the main
>>> benefit
>>> of not needing to ship everything with everything else. The killer
>>> feature
>>> is that developers can specify dependencies and users can have those
>>> dependencies installed automatically in a cross-platform way.  Everything
>>> else is complete noise if this use case is not served.
>>>
>>
>> Cool. This is the kind of thing we need recorded in a PEP - there's a
>> lot of domain knowledge floating around in the heads of packaging
>> folks that needs to be captured so we can know *what the addition of
>> packaging to the standard library is intended to fix*.
>>
>> And, like it or not, setuptools has a serious PR problem due to the
>> fact it monkeypatches the standard library, uses *.pth files to alter
>> sys.path for every installed application by default, actually *uses*
>> the ability to run code in *.pth files and has hard to follow
>> documentation to boot. I *don't* trust that I fully understand the
>> import system on any machine with setuptools installed, because it is
>> demonstrably happy to install state to the file system that will
>> affect *all* Python programs running on the machine.
>>
>
> I don't know about Red Hat but both Ubuntu and Apple put all kinds of
> stuff on the default sys.path of the system Python of the box that's
> related to their software's concerns only.  I don't understand why people
> accept this but get crazy about the fact that installing a setuptools
> distribution using easy_install changes the default sys.path.
>

I don't like the particular way that easy_install modifies sys.path so that
it can no longer be overridden by PYTHONPATH. For a discussion, see:
http://stackoverflow.com/questions/5984523/eggs-in-path-before-pythonpath-environment-variable

The fact that ubuntu does this for some system ubuntu packages has never
bothered me, but the fact that it happens for packages that I install with
easy_install has. The typical scenario would be that I:

1) Install some package X with easy_install.
2) Find a bug or some aspect of X that I want to change and checkout the
latest version from e.g. github.
3) Try to use PYTHONPATH to test the checked out version and find that
easy_install's path modification prevents me from doing so.
4) Run the quickfix script in the stackoverflow question above and consider
not using easy_install for X in future.

Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120621/97e00fe8/attachment.html>


More information about the Python-Dev mailing list