On 3/26/2012 12:27 PM, PJ Eby wrote:
On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer <c...@oddbird.net
<mailto:c...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
