Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
Hi, I too prefer venv (module) and pyvenv (script). Regards ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
Am 06.10.2011 16:12, schrieb Éric Araujo: Oh, let’s not forget naming. We can’t reuse the module name virtualenv as it would shadow the third-party module name, and I’m not fond of “virtualize”: it brings OS-level virtualization to my mind, not isolated Python environments. How about clutch? A virtualenv is a clutch of Python eggs, all ready to hatch. (Pun intended). :) Christian ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Thu, Oct 6, 2011 at 09:12, Éric Araujo mer...@netwok.org wrote: Oh, let’s not forget naming. We can’t reuse the module name virtualenv as it would shadow the third-party module name, and I’m not fond of “virtualize”: it brings OS-level virtualization to my mind, not isolated Python environments. How about we just drop the virtual part of the name and make it env? (or something non-virtual) ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Oct 06, 2011, at 04:12 PM, Éric Araujo wrote: I started to play with virtualenv recently and wondered about the status of the similar feature in 3.3 (cpythonv). The last thread mentioned two bugs; one has been fixed since. Apart from the implicit vs. explicit download of distribute, are there design issues to discuss? Can we do that with a patch on a bug report? Oh, let’s not forget naming. We can’t reuse the module name virtualenv as it would shadow the third-party module name, and I’m not fond of “virtualize”: it brings OS-level virtualization to my mind, not isolated Python environments. Time to hit the hardware store and stock up on bikeshed paint! I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid that picking something cute might make it harder to discover. `pythonv` or `cpythonv` seem like good choices to me. Maybe the former, so we could potentially have jythonv, etc. -Barry ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Thu, 6 Oct 2011 10:06:17 -0500 Brian Curtin brian.cur...@gmail.com wrote: On Thu, Oct 6, 2011 at 09:12, Éric Araujo mer...@netwok.org wrote: Oh, let’s not forget naming. We can’t reuse the module name virtualenv as it would shadow the third-party module name, and I’m not fond of “virtualize”: it brings OS-level virtualization to my mind, not isolated Python environments. How about we just drop the virtual part of the name and make it env? pythonenv? ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
Le 06/10/2011 17:31, Barry Warsaw a écrit : I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid that picking something cute might make it harder to discover. `pythonv` or `cpythonv` seem like good choices to me. Maybe the former, so we could potentially have jythonv, etc. I’m not sure we would. The feature is two-fold: - changes to getpath.c, site.py and other usual suspects so that CPython supports being run in an isolated environment; - a new module used to create isolated environments. The first part is implemented in CPython; the second part needs a module name to replace virtualenv. python -m pythonv doesn’t seem right. python -m makeenv? python -m workon? (idea from virtualenvwrapper) python -m nest? Cheers ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Thu, Oct 6, 2011 at 10:46, Éric Araujo mer...@netwok.org wrote: Le 06/10/2011 17:31, Barry Warsaw a écrit : I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid that picking something cute might make it harder to discover. `pythonv` or `cpythonv` seem like good choices to me. Maybe the former, so we could potentially have jythonv, etc. I’m not sure we would. The feature is two-fold: - changes to getpath.c, site.py and other usual suspects so that CPython supports being run in an isolated environment; - a new module used to create isolated environments. The first part is implemented in CPython; the second part needs a module name to replace virtualenv. python -m pythonv doesn’t seem right. python -m makeenv? python -m workon? (idea from virtualenvwrapper) python -m nest? develop? devenv? ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote: Le 06/10/2011 17:31, Barry Warsaw a écrit : I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid that picking something cute might make it harder to discover. `pythonv` or `cpythonv` seem like good choices to me. Maybe the former, so we could potentially have jythonv, etc. I’m not sure we would. The feature is two-fold: - changes to getpath.c, site.py and other usual suspects so that CPython supports being run in an isolated environment; - a new module used to create isolated environments. While the other implementations might not be able to share any of CPython's code, it's still a worthy feature for any Python implementation I think. The first part is implemented in CPython; the second part needs a module name to replace virtualenv. python -m pythonv doesn’t seem right. Nope, although `python -m virtualize` seems about perfect. I don't particularly like the -m interface though. Yes, it should work, but I also think there should be a command that basically wraps whatever the -m invocation is, just for user friendliness. python -m makeenv? python -m workon? (idea from virtualenvwrapper) python -m nest? Well, I have to be honest, I've *always* thought nest would be a good choice for a feature like this, but years ago (IIRC) PJE wanted to reserve that term for something else, which I'm not sure ever happened. There's a PyNEST project here: http://www.nest-initiative.uni-freiburg.de/index.php/PyNEST which might cause problems with a built-in `nest` module. Still, I'm a bit fond of `python -m nest` and a `pynest` wrapper. Barring that, `python -m virtualize` with an appropriate cli shortcut (`pysolate`? - say it out loud :) seems good. -Barry ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Thu, 6 Oct 2011 12:02:05 -0400 Barry Warsaw ba...@python.org wrote: The first part is implemented in CPython; the second part needs a module name to replace virtualenv. python -m pythonv doesn’t seem right. Nope, although `python -m virtualize` seems about perfect. `python -m sandbox` ? ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Éric, Vinay is more up to date than I am on the current status of the implementation. I need to update the PEP draft we worked on last spring and get it posted (the WIP is at https://bitbucket.org/carljm/pythonv-pep but is out of date with the latest implementation work). On 10/06/2011 08:12 AM, Éric Araujo wrote: Oh, let’s not forget naming. We can’t reuse the module name virtualenv as it would shadow the third-party module name, and I’m not fond of “virtualize”: it brings OS-level virtualization to my mind, not isolated Python environments. What about venv? It's short, it's already commonly used colloquially to refer to virtualenv so it makes an accurate and unambiguous mental association, but AFAIK it is currently unused as a script or module name. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6N0+QACgkQ8W4rlRKtE2fCOwCg1YOWcMCZH6HOdyKepcQG3RgB T48AoIIqol+sUpOAFI+4HJH/dAdX5Xwm =DLjq -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
- Original Message -
I started to play with virtualenv recently and wondered about the status
of the similar feature in 3.3 (cpythonv). The last thread mentioned two
bugs; one has been fixed since.
The pythonv branch is pretty much up to date with the default branch (3.3). I
regularly merge with default and post the results of running the Python
regression suite in a virtual environment - in fact I'm running such a test
right now :-). The test results and a screencast are linked from the project's
BitBucket page at
https://bitbucket.org/vinay.sajip/pythonv/
Apart from the implicit vs. explicit download of distribute, are there
design issues to discuss? Can we do that with a patch on a bug report?
I've made changes to get packaging to work well with virtualenv, some of which
I raised as packaging issues on the tracker. In some cases, I've fixed them in
the pythonv branch. The last bug is a problem with test_user_similar which has
an existing issue (#9100) in a non-virtual environment. This is not a
show-stopper, but I'm not really sure how the user scheme is supposed to work
in venvs: perhaps Carl has a view on this. BTW there have been intermittent
failures in test_packaging, too but they've generally been fixed by changes in
core).
In terms of design issues, it would be useful if someone (apart from me that
is) could look at how the pythonv fork differs from the core and comment on any
issues they find. (Much of the change can be summed up as replacing occurrences
of sys.prefix with sys.getattr('site_prefix', sys.prefix).)
BitBucket makes this type of comparison fairly easy to do; I'm not sure if
there's a lot of value in adding a patch on the tracker for Rietveld review,
until (and if) the PEP is accepted.
Re. distribute: At the moment the pythonv branch downloads a private version of
distribute. The only significant difference from the vanilla distribute is the
use of sys.site_prefix and sys.site_exec_prefix (falling back to sys.prefix and
sys.exec_prefix if we're not running distribute in a virtual env, so it's
backward compatible - but I didn't ask anyone in the packaging/distribute team
to port this small change across. The only reference to sys.site_prefix is this
code in setuptools/command/easy_install.py:
if hasattr(sys, 'site_prefix'):
prefixes = [sys.site_prefix]
else:
prefixes = [sys.prefix]
if sys.exec_prefix != sys.prefix:
prefixes.append(sys.exec_prefix)
If this were ported to distribute, that would be nice :-)
I think the plan is to remove the distribute-downloading functionality from the
stdlib. However, I am working on a companion project, nemo, which will have
this functionality and in addition provides virtualenvwrapper-like
functionality for Linux, Mac and Windows. (This is based on the stdlib API, is
WIP, not released yet, though shown in the screencast I mentioned earlier).
Oh, let’s not forget naming. We can’t reuse the module name virtualenv
as it would shadow the third-party module name, and I’m not fond of
“virtualize”: it brings OS-level virtualization to my mind, not isolated
Python environments.
I'm OK with Carl's suggestion of venv, and prefer it to Brian's suggestion of
env.
Regards,
Vinay Sajip
___
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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote: On Thu, 6 Oct 2011 12:02:05 -0400 Barry Warsaw ba...@python.org wrote: The first part is implemented in CPython; the second part needs a module name to replace virtualenv. python -m pythonv doesn’t seem right. Nope, although `python -m virtualize` seems about perfect. `python -m sandbox` ? That's nice too. -Barry ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
+1 for env or sandbox or something else with box in it. pythonbox? envbox? boxenv? ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Thu, Oct 6, 2011 at 12:02 PM, Barry Warsaw ba...@python.org wrote: Well, I have to be honest, I've *always* thought nest would be a good choice for a feature like this, but years ago (IIRC) PJE wanted to reserve that term for something else, which I'm not sure ever happened. Actually, it was pretty much for this exact purpose -- i.e. it was the idea of a virtual environment. Ian just implemented it first, with some different ideas about configuration and activation. Since this is basically the replacement for that, I don't have any objection to using the term here. (In my vision, nest was also the name of a package management tool for creating such nests and manipulating their contents, though.) ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On 10/06/11 18:02, Barry Warsaw wrote: On Oct 06, 2011, at 05:46 PM, Éric Araujo wrote: Le 06/10/2011 17:31, Barry Warsaw a écrit : I agree we can't use virtualenv, and shouldn't use virtualize. I'm afraid that picking something cute might make it harder to discover. `pythonv` or `cpythonv` seem like good choices to me. Maybe the former, so we could potentially have jythonv, etc. I’m not sure we would. The feature is two-fold: - changes to getpath.c, site.py and other usual suspects so that CPython supports being run in an isolated environment; - a new module used to create isolated environments. While the other implementations might not be able to share any of CPython's code, it's still a worthy feature for any Python implementation I think. The first part is implemented in CPython; the second part needs a module name to replace virtualenv. python -m pythonv doesn’t seem right. Nope, although `python -m virtualize` seems about perfect. Hmm, with proper interpreter support I don't see what would be so virtual about it anymore. Georg ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On 6 October 2011 17:02, Barry Warsaw ba...@python.org wrote: I don't particularly like the -m interface though. Yes, it should work, but I also think there should be a command that basically wraps whatever the -m invocation is, just for user friendliness. No problem with a wrapper, but the nice thing about the -m form is that it's portable. On Unix, shell script wrappers are pretty portable (no idea if C-shell users would agree...) On Windows, though, there are all sorts of problems. BAT files don't nest, so you end up having to use atrocities like CALL virtualenv within a batch file. Powershell users prefer .ps1 files. The only common form is an EXE, but nobody really likes having to use a compiled form every time. Paul. ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
Éric Araujo merwok at netwok.org writes: Oh, let’s not forget naming. We can’t reuse the module name virtualenv as it would shadow the third-party module name, and I’m not fond of “virtualize”: it brings OS-level virtualization to my mind, not isolated Python environments. Another possible name would be isolate: python -m isolate /project/env doesn't look too bad. There's no eponymous package on PyPI, and note also that in addition to the common usage of isolate as a verb, it's also a noun with an appropriate meaning in this context. Regards, Vinay Sajip ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Thu, Oct 6, 2011 at 12:50 PM, Barry Warsaw ba...@python.org wrote: On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote: On Thu, 6 Oct 2011 12:02:05 -0400 Barry Warsaw ba...@python.org wrote: The first part is implemented in CPython; the second part needs a module name to replace virtualenv. python -m pythonv doesn’t seem right. Nope, although `python -m virtualize` seems about perfect. `python -m sandbox` ? That's nice too. sandbox is a bit close to Victor's pysandbox for restricted execution environments. 'nest' would probably work, although I don't recall the 'egg' nomenclature featuring heavily in the current zipimport or packaging docs, so it may be a little obscure. 'pyenv' is another possible colour for the shed, although a quick Google search suggests that may have few name clash problems. 'appenv' would be yet another colour, since that focuses on the idea of 'environment per application'. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/06/2011 12:12 PM, Nick Coghlan wrote: sandbox is a bit close to Victor's pysandbox for restricted execution environments. 'nest' would probably work, although I don't recall the 'egg' nomenclature featuring heavily in the current zipimport or packaging docs, so it may be a little obscure. 'pyenv' is another possible colour for the shed, although a quick Google search suggests that may have few name clash problems. 'appenv' would be yet another colour, since that focuses on the idea of 'environment per application'. I still think 'venv' is preferable to any of the other options proposed thus far. It makes the virtualenv ancestry clearer, doesn't repeat py (which seems entirely unnecessary in the name of a stdlib module, though it could be prepended to a script name if we do a script), and doesn't try to introduce new semantic baggage to the concept, which is already familiar to most Python devs under the name virtualenv. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6N9H4ACgkQ8W4rlRKtE2doVACcChCim7CNS0czZisjEmw9NblS MqkAn1FyT+A/UiKodCh1siHrQXf2/yZQ =TAUV -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Oct 06, 2011, at 12:33 PM, Carl Meyer wrote: I still think 'venv' is preferable to any of the other options proposed thus far. It's also nicely unique for googling. Funnily enough, the top hit right now for 'venv' is apparently Lua's project of the same name for the same purpose. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOjfwcAAoJEBJutWOnSwa/JRwQALLgtxOAmI9dhgaxudZgsDS7 ZeyaKFTDp2gnteMwXPFv2KK0n1SCsCIzOj807xel8id2Mr5R4FeoBC/HmySSsbxv 2U29QxXHAl/a3pZ50C5a3O7ZV4DShXuPQC/Y430PkwAkrP1ydb/I7KQEgmvHe2A1 UJQ1zbdX+gadk6n9sUo7NuEtvL7lMQdDeGLXvflqRJrVLeGxYV3AHwjByBE6MggU n5tZNv5G/H4fr/pD0SoMlI7MKoWRJkdqAeo3ASySVDn8LXe9UNjJb21YW18RyZPv qcdTzD4NYLJy5FQCmG9N2mOGwUjvrt82kLkcoKcNBekY5TfELshlqgqn31n+bxPo yV4Mr2IFOpRFTW218hwPbpEGK6Mfe03AV59Qey0zSKOsiJPUiPhXu9XdozvlF+Bx 7OdvhTe2nQBf8lp/KaKj4uZnnAvA9C8mMoukn6ly0Kk0EcDw81Ls9nMYxg/3gH7b 0SfvJH+8uQBjXF24Ce/xQkm6D7cB5e9GeilruH9VZ4LfZXYpP7jMdvWhW0g2S4PD KJWChqetOajJBZmWWK0vSBuLAjVxJTZ0Y5q0k9BNOiFj8/5v3QvpCAXQFFv7LTcX RDPI8rk73qjZiyAsVHMOmjSZfpY3aJnhPVMBSn0++yCzWx+YQbPwWkt6VihC6Ve4 Od0WX6XSEEu5BxJYaM/v =/f38 -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
Lennart Regebro wrote: +1 for env or sandbox or something else with box in it. Eggbox? Eggcrate? Incubator? -- Greg ___ 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
Re: [Python-Dev] Status of the built-in virtualenv functionality in 3.3
On Thu, Oct 6, 2011 at 3:06 PM, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Oct 06, 2011, at 12:33 PM, Carl Meyer wrote: I still think 'venv' is preferable to any of the other options proposed thus far. It's also nicely unique for googling. Funnily enough, the top hit right now for 'venv' is apparently Lua's project of the same name for the same purpose. Yeah, I meant to say that 'venv' also sounded like a reasonable choice to me (for the reasons Carl listed). Chers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
