[Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)

[PJ Eby]

On Mar 23, 2012 1:37 PM, "VanL" <van.lindberg at gmail.com> wrote:
>
> On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:
>>
>> Even if you are using tools that don't use distutils' configuration
settings for these directories, why not simply fix those tools so that they
do?
>
>
> Thats what I do currently - I set things to bin and patch Python and the
tools so that they work.

Patch *Python*?  Where?  Are you talking about the distutils/distutils.cfg
file?

My point here is that AFAIK, Python already supports your desired layout -
so your use case doesn't provide much of an argument in favor of making it
the default.

> However, have considered this to be a little bit of a wart anyway for a
long time - even before I adopted my current method of working - because it
is a pointless inconsistency.

In other words, that's the real reason - which, as it's already been
pointed out, is not much of an argument in favor of changing it.
Consistency with previous Python releases seems a far more *useful*
consistency to maintain than cross-platform consistency, which is only of
relevance to cross-platform developers -- at best only a subset of the
Windows developer audience.

Worse, changing it means that tools have to grow version-specific code, not
just platform-specific code.

> The fact that it makes virtual environments consistent across platforms,

Not really seeing a point.  Home directory layouts, "develop" installs,
.pth files, -m scripts... there are *zillions* of ways to develop code in
cross-platform directory layouts, including the one you're using now.

Tool developers are going "meh" about your proposal because it doesn't
actually solve any problems for them: they still have to support the old
layout, and if their code already uses distutils' facilities for obtaining
paths, there's nothing they gain from the change.

IOW, the only person who gains from the consistency is someone who wants
their virtualenv's to look the same and check them into source.  I'm really
not seeing this as being a big enough group to be worth inconveniencing
other people for, vs. telling them to add bin/ to PATH on Windows and edit
a distutils config file.  At best, this might be deserving of a FAQ entry
on how to set up cross platform development environments.

AFAICT, virtualenvs are overkill for most development anyway.  If you're
not using distutils except to install dependencies, then configure
distutils to install scripts and libraries to the same directory, and then
do all your development in that directory.  Presto!  You now have a
cross-platform "virtualenv".  Want the scripts on your path?  Add that
directory to your path... or if on Windows, don't bother, since the current
directory is usually on the path.   (In fact, if you're only using
easy_install to install your dependencies, you don't even need to edit the
distutils configuration, just use "-md targetdir".)

The entire virtualenv concept was originally introduced as a way for
non-root *nix users to have private site-packages directories with .pth
support, in order to be able to install eggs -- a use case which was then
solved by user-specific site directories in Python 2.6, and the addition of
the site.py hacks in easy_install (to allow any directory to be a
virtualenv as far as easy_install was concerned).

Virtualenv seem to have caught on for a variety of other uses than that,
but AFAIK, that's only because it's the most *visible* solution for those
uses.  Just dumping things in a directory adjacent to the corresponding
scripts is the original virtualenv, and it still works just dandy -- most
people just don't *know* this.  (And again, if there are tools out there
that *don't* support single-directory virtualenvs, the best answer is
probably to fix them.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120323/34c7215e/attachment.html>