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

[Carl Meyer]

On 03/23/2012 09:22 PM, PJ Eby wrote:
> On Mar 23, 2012 3:53 PM, "Carl Meyer" <carl at oddbird.net
>> On 03/23/2012 12:35 PM, PJ Eby wrote:
>> > 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".)
>>
>> Creating and using a virtualenv is, in practice, _easier_ than any of
>> those alternatives,
> 
> Really?  As I said, I've never seen the need to try, since just
> installing stuff to a directory on PYTHONPATH seems quite easy enough
> for me.
> 
>> that the "isolation from system site-packages" feature is quite popular
>> (the outpouring of gratitude when virtualenv went isolated-by-default a
>> few months ago was astonishing), and AFAIK none of your alternative
>> proposals support that at all.
> 
> What is this isolation for, exactly?  If you don't want site-packages on
> your path, why not use python -S?
> 
> (Sure, nobody knows about these things, but surely that's a
> documentation problem, not a tooling problem.)
> 
> Don't get me wrong, I don't have any deep objection to virtualenvs, I've
> just never seen the *point* (outside of the scenarios I mentioned),

No problem. I was just responding to the assertion that people only use
virtualenvs because they aren't aware of the alternatives, which I don't
believe is true. It's likely many people aren't aware of python -S, or
of everything that's possible via distutils.cfg. But even if they were,
for the cases where I commonly see virtualenv in use, it solves the same
problems more easily and with much less fiddling with config files and
environment variables.

Case in point: libraries that also install scripts for use in
development or build processes. If you're DIY, you have to figure out
where to put these, too, and make sure it's on your PATH. And if you
want isolation, not only do you have to remember to run python -S every
time, you also have to edit every script wrapper to put -S in the
shebang line. With virtualenv+easy_install/pip, all of these things Just
Simply Work, and (mostly) in an intuitive way. That's why people use it.

> thus don't see what great advantage will be had by rearranging layouts
> to make them shareable across platforms, when "throw stuff in a
> directory" seems perfectly serviceable for that use case already.  Tools
> that *don't* support "just throw it in a directory" as a deployment
> option are IMO unpythonic -- practicality beats purity, after all.  ;-)

No disagreement here. I think virtualenv's sweet spot is as a convenient
tool for development environments (used in virtualenvwrapper fashion,
where the file structure of the virtualenv itself is hidden away and you
never see it at all). I think it's fine to deploy _into_ a virtualenv,
if you find that convenient too (though I think there are real
advantages to deploying just a big ball of code with no need for
installers). But I see little reason to make virtualenvs relocatable or
sharable across platforms. I don't think virtualenvs as on on-disk file
structure make a good distribution/deployment mechanism at all.

IOW, I hijacked this thread (sorry) to respond to a specific denigration
of the value of virtualenv that I disagree with. I don't care about
making virtualenvs consistent across platforms.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120326/764572b0/attachment.pgp>