<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
On 3/26/2012 12:27 PM, PJ Eby wrote:
<blockquote
cite="mid:CALeMXf5Oz43pAmE4UCGtRKfiBPg-7zuyupsBLqPAzHiEFnzeqQ@mail.gmail.com"
type="cite">On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:carl@oddbird.net">carl@oddbird.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">No disagreement here. I think virtualenv's sweet
spot is as a convenient</div>
tool for development environments (used in virtualenvwrapper
fashion,<br>
where the file structure of the virtualenv itself is hidden away
and you<br>
never see it at all). I think it's fine to deploy _into_ a
virtualenv,<br>
if you find that convenient too (though I think there are real<br>
advantages to deploying just a big ball of code with no need for<br>
installers). But I see little reason to make virtualenvs
relocatable or<br>
sharable across platforms. I don't think virtualenvs as on
on-disk file<br>
structure make a good distribution/deployment mechanism at all.<br>
<br>
IOW, I hijacked this thread (sorry) to respond to a specific
denigration<br>
of the value of virtualenv that I disagree with. I don't care
about<br>
making virtualenvs consistent across platforms.<br>
</blockquote>
<div><br>
</div>
<div>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!</div>
</blockquote>
<br>
What I read here is a bit different than Mr Eby read, it seems.<br>
<br>
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).<br>
<br>
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?<br>
<br>
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.<br>
<br>
</body>
</html>