[Python-Dev] Status of packaging in 3.3 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Jun 21 17:48:24 CEST 2012

On Fri, Jun 22, 2012 at 12:59 AM, Chris McDonough <chrism at plope.com> wrote:

On 06/21/2012 10:30 AM, Nick Coghlan wrote:

That will give at least 3 mechanisms for Python code to get onto a system:

1. Python dist ->  converter ->  system package ->  system Python path 2. Python dist ->  system Python installer ->  system Python path 3. Python dist ->  venv Python installer ->  venv Python path While I agree that path 2 should be discouraged for production systems, I don't think it should be prevented altogether (since it can be very convenient on personal systems). I'm not sure under what circumstance 2 and 3 wouldn't do the same thing.  Do you have a concrete idea?

Yep, this is what I was talking about in terms of objecting to installation of *.pth files: I think automatically installing *.pth files into the system Python path is wrong (just like globally editing PYTHONPATH), and that includes any *.pth files needed for egg installation.

In a venv however, I assume the entire thing is application specific, so using *.pth files and eggs for ease of management makes a lot of sense and I would be fine with using that style of installation by default.

If the same default was going to the used in both places, my preference would be to avoid *.pth files by default and require them to be explicitly requested regardless of the nature of the target environment. I really just wanted to be clear that I don't mind *.pth files at all in the venv case, because they're not affecting the runtime state of other applications.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list