[Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
v+python at g.nevcal.com
Mon Mar 26 22:21:41 CEST 2012
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
> 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
> structure make a good distribution/deployment mechanism at all.
> IOW, I hijacked this thread (sorry) to respond to a specific
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev