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
On Thu, Oct 6, 2011 at 3:06 PM, Barry Warsaw 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 eno
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.pytho
-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
-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 zipim
On Thu, Oct 6, 2011 at 12:50 PM, Barry Warsaw wrote:
> On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote:
>
>>On Thu, 6 Oct 2011 12:02:05 -0400
>>Barry Warsaw wrote:
>>>
>>> >The first part is implemented in CPython; the second part needs a module
>>> >name to replace virtualenv. python -m pyth
Éric Araujo 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
On 6 October 2011 17:02, Barry Warsaw 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 abou
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
>
On Thu, Oct 6, 2011 at 12:02 PM, Barry Warsaw 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 pre
+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/arch
On Oct 06, 2011, at 06:04 PM, Antoine Pitrou wrote:
>On Thu, 6 Oct 2011 12:02:05 -0400
>Barry Warsaw 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 virt
- 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
regul
-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
late
On Thu, 6 Oct 2011 12:02:05 -0400
Barry Warsaw 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` ?
_
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. Ma
On Thu, Oct 6, 2011 at 10:46, É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. M
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
On Thu, 6 Oct 2011 10:06:17 -0500
Brian Curtin wrote:
> On Thu, Oct 6, 2011 at 09:12, É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 virtual
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
On Thu, Oct 6, 2011 at 09:12, É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.
How ab
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 clut
Hi,
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 wi
23 matches
Mail list logo
