<p><br>
On Mar 23, 2012 1:37 PM, "VanL" <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a>> wrote:<br>
><br>
> On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:<br>
>><br>
>> 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? <br>
><br>
><br>
> Thats what I do currently - I set things to bin and patch Python and the tools so that they work.</p>
<p>Patch *Python*? Where? Are you talking about the distutils/distutils.cfg file?</p>
<p>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.</p>
<p>> 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.</p>
<p>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.</p>
<p>Worse, changing it means that tools have to grow version-specific code, not just platform-specific code.</p>
<p>> The fact that it makes virtual environments consistent across platforms, </p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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".)</p>
<p>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).</p>
<p>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.) </p>