[Python-Dev] Python install layout and the PATH on win32

Thu Mar 15 00:30:54 CET 2012

[resending - original reply went only to Van]
On 15/03/2012 10:15 AM, Lindberg, Van wrote:
 > On 3/14/2012 5:39 PM, Mark Hammond wrote:
 >> Can you offer any examples of 3rd party tools which could unify code
 >> in this scheme, and particularly, where this scheme would cause them
 >> to have less code, not more?
 >
 > How about virtualenv:
 >
 > """
 > def path_locations(home_dir):
 > """Return the path locations for the environment (where libraries 
are,
 > where scripts go, etc)"""
 > # XXX: We'd use distutils.sysconfig.get_python_inc/lib but its
 > # prefix arg is broken: http://bugs.python.org/issue3386
 > if sys.platform == 'win32':
 > [snip a bit about spaces in the path....]
 > lib_dir = join(home_dir, 'Lib')
 > inc_dir = join(home_dir, 'Include')
 > bin_dir = join(home_dir, 'Scripts')
 > if is_jython:
 > lib_dir = join(home_dir, 'Lib')
 > inc_dir = join(home_dir, 'Include')
 > bin_dir = join(home_dir, 'bin')
 > elif is_pypy:
 > lib_dir = home_dir
 > inc_dir = join(home_dir, 'include')
 > bin_dir = join(home_dir, 'bin')
 > elif sys.platform != 'win32':
 > lib_dir = join(home_dir, 'lib', py_version)
 > inc_dir = join(home_dir, 'include', py_version + abiflags)
 > bin_dir = join(home_dir, 'bin')
 > return home_dir, lib_dir, inc_dir, bin_dir
 > """
So what would that look like in your scheme? I'd expect you wind up with:
if sys.platform == 'win32' and sys.versioninfo < (3,4):
 ... existing layout
else:
 ... new layout.
So it actually ends up as slightly *more* code.
 >
 >
 >> I think you misunderstand the .bat file - there is no python
 >> executable in the bin directory. The bat file is locating your
 >> already installed Python and attempting to use it.
 >
 > My only point here is that it would still find the already-installed
 > Python (I think).
I'm fairly sure it would not - it doesn't look in %PYTHONINSTALL%\bin.
 >
 >> My other questions still remain: who specifically will benefit from
 >> this, and what would be the cost to those beneficiaries of sticking
 >> with the existing scheme?
 >
 > I will benefit, for one. My use case is that I do cross-platform
 > development and deployment, and I occasionally want to put an entire
 > environment in source control. Currently the case changing and
 > Scripts/bin distinction make this a distinct pain, such that I go in 
 > and edit my Windows python installation in the way that I am
 > describing right now.
 >
 > From my actual experience with this layout, pip, virtualenv, and
 > pypm are the only three major packages that hard-code this logic and
 > would need to be changed slightly.
So why not just standardize on that new layout for virtualenvs?
Mark