On Fri, Jun 22, 2012 at 12:59 AM, Chris McDonough <chr...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
