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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4