Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Paul Moore]

On 19 September 2015 at 19:37, Brett Cannon  wrote:
> Guys, this thread is about removing the pyvenv script, not pip. If you want
> to start a discussion about pip and its command structure that should
> probably happen on pip's issue tracker or over at distutils-sig.

Sorry, good point.

Back to the original question, I'm +1 on deprecating pyvenv as described.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Brett Cannon]

Guys, this thread is about removing the pyvenv script, not pip. If you want
to start a discussion about pip and its command structure that should
probably happen on pip's issue tracker or over at distutils-sig.

On Sat, 19 Sep 2015 at 10:37 Sven R. Kunze  wrote:

> On 19.09.2015 19:19, Paul Moore wrote:
> > I thought my point was "yes, go for it - your code contribution would
> > be appreciated" :-) Paul
>
> Well, before coding shouldn't we have vision and a plan for pip somehow
> and pinpoint it somewhere where everybody who's willing to contribute
> can see it?
>
> Don't get me wrong, I'd be glad to contribute code (what I've already
> done to other open-source projects), but I feel somewhat disoriented
> when in comes to "Python core".
>
> Best,
> Sven
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Stephen J. Turnbull]

Terry Reedy writes:

 > Am I correct in guessing that on Windows, at least, R and Emacs do *not* 
 > run in Command Prompt?

I'm not sure what you mean by that.  Of course they do run under
Command Prompt, but the limitations of the command window are so
severe that almost nobody ever does that, they click on an icon to
start.  Nevertheless the basic interactions that are always available
are command-shell-like (as in IDLE), although there are icon- or menu-
driven GUI shells or modes available for each.

In Emacs, the basic interface is the "list-packages" command, which
brings up a (text) menu of installed and available packages on the
ELPA package repository.  In R, it's the package.install() function,
which I think has a subfeature that will list the packages available
from the CRAN package repository (but I always just go to the
website).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Sven R. Kunze]

On 19.09.2015 07:24, Stephen J. Turnbull wrote:

Barry Warsaw writes:

  > One thing that came up in a similar discussion is pip, and the
  > suggested move to `python -m pip`, which makes a lot of sense.
  > However, *inside* a virtualenv, there's no ambiguity about the
  > Python version associated with direct `pip` invocation, so it still
  > makes sense to install that there.

And then the poor newbie who's just following orders (eg, in
mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of
the virtualenv for some reason, and have a WTF experience.  I think we
should KISS the pip command good-bye.


The only question I have: is there a particular reason (not technical 
one) why there are many pips on my PC?


I would imagine 1 pip for the whole OS, that is capable to install 
packages inside arbitrary venvs AND handles different versions of Python.



Best,
Sven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Paul Moore]

On 19 September 2015 at 06:49, Terry Reedy  wrote:
> On 9/19/2015 1:24 AM, Stephen J. Turnbull wrote:
>>
>> Barry Warsaw writes:
>>
>>   > One thing that came up in a similar discussion is pip, and the
>>   > suggested move to `python -m pip`, which makes a lot of sense.
>>   > However, *inside* a virtualenv, there's no ambiguity about the
>>   > Python version associated with direct `pip` invocation, so it still
>>   > makes sense to install that there.
>>
>> And then the poor newbie who's just following orders (eg, in
>> mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of
>> the virtualenv for some reason, and have a WTF experience.  I think we
>> should KISS the pip command good-bye.
>>
>> A somewhat different way I look at it: the OS provides a shell, and
>> you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI
>> shell) from that OS shell to manage OS packages.  By analogy (always
>> slippery but this one feels good to me), to manage python packages you
>> should be working in the Python "shell".
>
>
> It is somewhat possible to do this by importing pip.main and translating pip
> command line calls to main() calls. I reported proof-of-concept experiments
> on issue 23551. To be practical, this should be wrapped in a tkinter gui.
> Once written, I will add it to the Idle menu.  Other gui shells, could and
> probably would do the same.

I've raised https://github.com/pypa/pip/issues/3121 as a starting
point for discussion on how pip could support a high-level Python API
(i.e. make pip.main a bit less "you're on your own"). I don't have any
plans right now to work on it, but it provides somewhere to centralise
any discussion (and of course, if anyone *else* feels like
contributing patches, that'd be great too ;-))

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Paul Moore]

On 19 September 2015 at 10:12, Sven R. Kunze  wrote:
> The only question I have: is there a particular reason (not technical one)
> why there are many pips on my PC?

That's not an unreasonable question, but (IMO) most of the answers are
technical, or amount to "why would you think that's wrong". So
apologies, I do know this isn't a direct answer to your question.

1. There are a lot of ways in which pip's implementation assumes it's
installing modules for the Python installation that is running it.
2. We have no installation process or path management to allow you to
install a Python package *outside* of a Python installation and run it
with the user's choice of Python.
3. You've got lots of pythons on your PC (otherwise you wouldn't have
lots of pips!) so why do you think it's *not* equally reasonable to
have lots of pips?
4. The "py" launcher (on Windows) manages your multiple Pythons for
you - it can also manage pip if you don't mind using "py -m pip" to
invoke pip. You can of course alias this (wrap it in a powershell
function, bat file, shell script or whatever) as you choose.

So, to directly answer:

Because there are technical challenges that no-one has stepped up to solve.

I would assume you're thinking of a "single pip" in the same way that
the py.exe launcher is a "single python". Assuming so, then the
"single pip" solution is "py -m pip" (leveraging py.exe's options for
picking which Python to use). I don't know if there's a Unix
equivalent to the launcher - if not, then maybe there should be?

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Sven R. Kunze]

On 19.09.2015 14:44, Paul Moore wrote:

On 19 September 2015 at 10:12, Sven R. Kunze  wrote:

The only question I have: is there a particular reason (not technical one)
why there are many pips on my PC?

That's not an unreasonable question, but (IMO) most of the answers are
technical, or amount to "why would you think that's wrong". So
apologies, I do know this isn't a direct answer to your question.

1. There are a lot of ways in which pip's implementation assumes it's
installing modules for the Python installation that is running it.


We need to cope with that in some way.


2. We have no installation process or path management to allow you to
install a Python package *outside* of a Python installation and run it
with the user's choice of Python.


I wouldn't go so far so put the installation somewhere else. The current 
site-packages is good enough (although, it's a somewhat strange name).


But what I would love to see is a real package management, where 
installing packages is safe (asking when overriding existing files), 
where I can have proper upgrading/downgrading, query dependencies, query 
installed files/scripts/data, query redundant packages and so on and so 
forth. Just like zypper, apt-get or its kind. We get there but I fear it 
will be a long time before Python gets the package management it deserves.


pip = Python installs Python. That's how it started; however, real 
package management is far more.



3. You've got lots of pythons on your PC (otherwise you wouldn't have
lots of pips!) so why do you think it's *not* equally reasonable to
have lots of pips?


pip happens to use Python but both serve different purposes. Why it's 
not reasonable? Good question, the best answer I can come up with is 
that "just invoking pip" does not tell you what Python it is going to 
un-/install packages for. You see it (when it's installing), but would 
be step forward to be asked kindly if I am okay with the installation 
location (and user+group permissions) and if not I could change it. 
Something like this. I think it's the usability I am really concerned with.



4. The "py" launcher (on Windows) manages your multiple Pythons for
you - it can also manage pip if you don't mind using "py -m pip" to
invoke pip. You can of course alias this (wrap it in a powershell
function, bat file, shell script or whatever) as you choose.


Interesting. So, py knows the location of all Python installations. What 
about py knows about all venvs? Then it could manage them in one place.



So, to directly answer:

 Because there are technical challenges that no-one has stepped up to solve.


Let's solve them. :)

Best,
Sven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Paul Moore]

On 19 September 2015 at 18:15, Sven R. Kunze  wrote:
>> So, to directly answer:
>>
>>  Because there are technical challenges that no-one has stepped up to
>> solve.
>
>
> Let's solve them. :)

I thought my point was "yes, go for it - your code contribution would
be appreciated" :-)
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Sven R. Kunze]

On 19.09.2015 19:19, Paul Moore wrote:
I thought my point was "yes, go for it - your code contribution would 
be appreciated" :-) Paul 


Well, before coding shouldn't we have vision and a plan for pip somehow 
and pinpoint it somewhere where everybody who's willing to contribute 
can see it?


Don't get me wrong, I'd be glad to contribute code (what I've already 
done to other open-source projects), but I feel somewhat disoriented 
when in comes to "Python core".


Best,
Sven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Nick Coghlan]

On 18 September 2015 at 05:04, Barry Warsaw  wrote:
> On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote:
>
>>I propose that the pyvenv script be deprecated in Python 3.5.1 and
>>removed in Python 3.8. The reason for this proposal is because it is
>>non-obvious what version of Python a pyvenv command is tied to (heck,
>>it isn't necessarily obvious that it's Python 3).
>
> That's why in Debian/Ubuntu we include /usr/bin/pyvenv-X.Y for all supported
> versions (currently 3.4 and 3.5 in Ubuntu 15.10), and then symlink
> /usr/bin/pyvenv to the default one.  So I'm sympathetic to this proposal.

I currently use pyvenv directly, but I agree with starting a migration
to only supporting the more explicit "python -m venv". There's always
an inherent ambiguity on *nix with unqualified version sensitive
Python commands as to whether they're referring to Python 2 or 3, as
the answer often depends on *how old* the particular script is  (e.g.
pip and virtualenv relate to the Python 2 installation, while pyvenv
relates to the Python 3 installation).

There's one slightly oddity in the migration, which is that "pyvenv"
will still run even if you're in an activated Python 2 virtual
environment, while "python -m venv" fails. The answer is to use a
qualified Python version in the latter call.

I assume the change to the script will include forcing that particular
deprecation warning to be visible by default.

Regards,
Nick.


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Stephen J. Turnbull]

Barry Warsaw writes:

 > One thing that came up in a similar discussion is pip, and the
 > suggested move to `python -m pip`, which makes a lot of sense.
 > However, *inside* a virtualenv, there's no ambiguity about the
 > Python version associated with direct `pip` invocation, so it still
 > makes sense to install that there.

And then the poor newbie who's just following orders (eg, in
mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of
the virtualenv for some reason, and have a WTF experience.  I think we
should KISS the pip command good-bye.

A somewhat different way I look at it: the OS provides a shell, and
you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI
shell) from that OS shell to manage OS packages.  By analogy (always
slippery but this one feels good to me), to manage python packages you
should be working in the Python "shell".  R does it that way with
great success.  Emacsen do it (with lesser success :-P ).  perl and
TeX don't -- but they don't have interactive shells (at least not
universally available to the users).

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Nick Coghlan]

On 19 September 2015 at 01:16, Barry Warsaw  wrote:
> On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote:
>
>>I currently use pyvenv directly, but I agree with starting a migration
>>to only supporting the more explicit "python -m venv". There's always
>>an inherent ambiguity on *nix with unqualified version sensitive
>>Python commands as to whether they're referring to Python 2 or 3, as
>>the answer often depends on *how old* the particular script is  (e.g.
>>pip and virtualenv relate to the Python 2 installation, while pyvenv
>>relates to the Python 3 installation).
>
> On Debian, we often use things like -2 or -3 suffixes, but there's no naming
> standard, and you inevitably get to monstrosities like nose2-3. ;)   For
> scripts which have to be Python-version specific, the slight loss of usability
> for `python -m blah` outweighs the ambiguity and ugliness of the direct
> alternative.
>
>>There's one slightly oddity in the migration, which is that "pyvenv"
>>will still run even if you're in an activated Python 2 virtual
>>environment, while "python -m venv" fails. The answer is to use a
>>qualified Python version in the latter call.
>
> One thing that came up in a similar discussion is pip, and the suggested move 
> to
> `python -m pip`, which makes a lot of sense.  However, *inside* a virtualenv,
> there's no ambiguity about the Python version associated with direct `pip`
> invocation, so it still makes sense to install that there.

Right. This is moving more into python-ideas and/or distutils-sig
territory, but this point also gave me an idea regarding what we might
want to do with the "python" command on Linux systems that have
migrated to using Python 3 as the system Python: what if we agreed to
change "python" on Linux systems to be a script that launches a
"default" virtual environment stored in the user's home directory
(location TBD), and similarly changed the unqualified system "pip"
command to manipulate that default virtual environment?

The question of "Which Python does 'python' run and 'pip' manipulate?"
would then be determined by how that default virtual environment was
set up rather than using a distro specific runtime switching
technology. If could either be Python 2.7 based using virtualenv, or
else a native Python 3 venv. Switching to a different default runtime
(e.g. PyPy) would be a matter of replacing that default virtual
environment with one created using a different interpreter. (This
approach would likely also deal with the perennial "Should pip default
to --user for global installs?" question).

Presumably, we could figure out a way to make that work on Windows as
well, such that "python" and "pip" *always* meant activating and
working in the user's default virtual environment, if there wasn't
already a virtual environment activated.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Terry Reedy]

On 9/19/2015 1:24 AM, Stephen J. Turnbull wrote:

Barry Warsaw writes:

  > One thing that came up in a similar discussion is pip, and the
  > suggested move to `python -m pip`, which makes a lot of sense.
  > However, *inside* a virtualenv, there's no ambiguity about the
  > Python version associated with direct `pip` invocation, so it still
  > makes sense to install that there.

And then the poor newbie who's just following orders (eg, in
mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of
the virtualenv for some reason, and have a WTF experience.  I think we
should KISS the pip command good-bye.

A somewhat different way I look at it: the OS provides a shell, and
you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI
shell) from that OS shell to manage OS packages.  By analogy (always
slippery but this one feels good to me), to manage python packages you
should be working in the Python "shell".


It is somewhat possible to do this by importing pip.main and translating 
pip command line calls to main() calls. I reported proof-of-concept 
experiments on issue 23551. To be practical, this should be wrapped in a 
tkinter gui.  Once written, I will add it to the Idle menu.  Other gui 
shells, could and probably would do the same.



R does it that way with
great success.  Emacsen do it (with lesser success :-P ).   perl and
TeX don't -- but they don't have interactive shells (at least not
universally available to the users).


Am I correct in guessing that on Windows, at least, R and Emacs do *not* 
run in Command Prompt?


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Barry Warsaw]

On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote:

>I currently use pyvenv directly, but I agree with starting a migration
>to only supporting the more explicit "python -m venv". There's always
>an inherent ambiguity on *nix with unqualified version sensitive
>Python commands as to whether they're referring to Python 2 or 3, as
>the answer often depends on *how old* the particular script is  (e.g.
>pip and virtualenv relate to the Python 2 installation, while pyvenv
>relates to the Python 3 installation).

On Debian, we often use things like -2 or -3 suffixes, but there's no naming
standard, and you inevitably get to monstrosities like nose2-3. ;)   For
scripts which have to be Python-version specific, the slight loss of usability
for `python -m blah` outweighs the ambiguity and ugliness of the direct
alternative.

>There's one slightly oddity in the migration, which is that "pyvenv"
>will still run even if you're in an activated Python 2 virtual
>environment, while "python -m venv" fails. The answer is to use a
>qualified Python version in the latter call.

One thing that came up in a similar discussion is pip, and the suggested move to
`python -m pip`, which makes a lot of sense.  However, *inside* a virtualenv,
there's no ambiguity about the Python version associated with direct `pip`
invocation, so it still makes sense to install that there.

Cheers,
-Barry


pgpltiap26Kr2.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Proposing the deprecation of the pyvenv script

[Brett Cannon]

I opened http://bugs.python.org/issue25154 for this idea and below is
what I put in the issue as to why I think we should deprecate the
pyvenv script in favour of `python3 -m venv`.


I propose that the pyvenv script be deprecated in Python 3.5.1 and
removed in Python 3.8. The reason for this proposal is because it is
non-obvious what version of Python a pyvenv command is tied to (heck,
it isn't necessarily obvious that it's Python 3). There would be no
loss in functionality since the exact same functionality is available
through `python3 -m venv`. This is a backwards-compatibility change,
hence the deprecation, but changing various shell scripts and such
should be trivial thanks to the -m flag. This would also help promote
the use of -m, especially for any projects that rely on being tied to
a specific installed interpreter.

As pointed out in issue #25152 ,
virtualenv provides a -p flag to specify what version of Python should
be used to create a virtual environment:
https://virtualenv.pypa.io/en/latest/reference.html#virtualenv-command.
The pyvenv script and venv package provide no such mechanism since it
is included in the stdlib, which makes sense since improvements will
be tied to the stdlib of the Python interpreter being used while
virtualenv is a standalone project/app.

Some may argue that worrying about this is unnecessary, but we are
already ending up with OSs that come with multiple versions of Python
pre-installed, let alone when people install their own versions of
Python on top of the system installation. For instance, OS X Yosemite
comes with Python 2.6 and 2.7, and then if you install the latest
version of Python independently you end up with 3 installations. If
they all happened to have a pyvenv script you wouldn't easily know
which Python interpreter the pyvenv command was going to use for the
virtual environment.

Since the pyvenv script is just a script, the deprecation will be in
the form of a message printed to sys.stderr in the
Tools/scripts/pyvenv
 file
mentioning that the deprecation and that people should switch to
`python3 -m venv` instead. The long deprecation cycle is for those who
have pyvenv provided by their OS and only upgrade Python every few
years, and thus run the risk of missing the deprecation warning. As
for the deprecation in Python 3.5.1, that's to get the warning out
immediately and to minimize people missing the deprecation prior to
the removal.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Barry Warsaw]

On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote:

>I propose that the pyvenv script be deprecated in Python 3.5.1 and
>removed in Python 3.8. The reason for this proposal is because it is
>non-obvious what version of Python a pyvenv command is tied to (heck,
>it isn't necessarily obvious that it's Python 3).

That's why in Debian/Ubuntu we include /usr/bin/pyvenv-X.Y for all supported
versions (currently 3.4 and 3.5 in Ubuntu 15.10), and then symlink
/usr/bin/pyvenv to the default one.  So I'm sympathetic to this proposal.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com