[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4