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

[Glenn Linderman]

On 3/26/2012 12:27 PM, PJ Eby wrote:
> On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer <carl at oddbird.net 
> <mailto:carl at oddbird.net>> wrote:
>
>     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.
>
>
> Well, if you're the virtualenv maintainer (or at least the PEP 
> author), and you're basically shooting down the principal rationale 
> for reorganizing the Windows directory layout, then it's not really 
> much of a hijack - it's pretty darn central to the thread!

What I read here is a bit different than Mr Eby read, it seems.

I read Carl as suggesting that keeping deployment copies of virtualenvs 
as foolish, but thinking it is fine to deploy into a virtualenv file 
structure (although preferring to deplay a big ball of code, himself).

Personally, I see application deployment as a big ball of code the 
preferred technique also, but library/module deployment is harder to do 
that way... it sort of defeats the ability to then bundle the 
library/module into the big ball of code for the application.  But if 
the goal is to deploy a big ball of code, that would run on top of an 
installed Python or virtualenv Python, then that is a lot easier if the 
only modules used are Python modules (no C extensions). Such can be 
bundled into a zip file, with little support, such that a relative 
Python novice as myself can figure it out and implement it quickly. C 
extensions cannot be run from a zip file, so then one needs support code 
to unzip the C binaries dynamically, and (possibly) delete them when 
done.  Or am I missing something?

Hmm. And here's something else that might be missing: integration of the 
launcher with .py files that are actually ZIP archives... where does it 
find the #! line? (probably it can't, currently -- I couldn't figure out 
how to make it do it).  Is it possible to add a #! line at the beginning 
of a ZIP archive for the launcher to use, and still have Python 
recognize the result as a ZIP archive? I know self-extracting archives 
put an executable program in front of a ZIP file, and the result is 
still recognized by most ZIP archivers, but I tried just putting a #! 
line followed by a ZIP archive, and Python gave me SyntaxError: unknown 
decode error.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120326/6369a16b/attachment-0001.html>