Re: [Distutils] The future of invoking pip

[Chris Barker]

On Thu, Nov 12, 2015 at 11:16 PM, Nathaniel Smith  wrote:

> >  > If we waved our hands and were able to magically make Python package
> >> management perfect, what would that look like?
> >
> > well, I think the command would be:
> >
> > python install package_name
> >
> > I know there are good reasons to keep package installer development out
> of
> > core, but if have ensurepip-- we could do this.
>
> 1) What about 'pip uninstall', 'pip freeze', 'pip list', 'pip show',
> 'pip search', 'pip wheel'?
>

hmm -- half of those are "advanced" features, but yes, there are a few that
newbies want easy access to, so how about :

python pip install
python pip search
...

just doesn't need the  "-m" -- which is a bit of advanced python voodoo
(OK, not very advanced...)

or maybe:

python install search
python install list
python install 

though that would make it tough to have a package called "search", etc...

what I'm getting at is that it makes plenty of sense for package management
to be seen as a feature of the python interpreter itself -- maybe slightly
more typing that "pip" (less than easy_install?) -- but no one is going to
be surprised that you use python to manage your python installation.

\2) If it requires python 3.6 it's kinda a non-starter...
>

well, this was a response to "magically make Python package management
perfect"

but anyway, there is always 2.7.11 :-) -- or would it even be possible to
hack a change to the command line handling with a package install? somehow
I doubt it.

and it may not be SO bad to require the -m pip for all legacy versions

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nick Coghlan]

On 13 November 2015 at 03:08, Brett Cannon  wrote:
>
>
> On Wed, 11 Nov 2015 at 04:06 Paul Moore  wrote:
>>
>> On 11 November 2015 at 06:35, Nick Coghlan  wrote:
>> > Windows Python 2 installations require manual PATH modifications
>> > regardless, but it's more common for people to know how to make
>> > "python -m pip install X" work, than it is for them to remember to
>> > also add the "Scripts" directory needed to make "pip install X" work.
>>
>> ... and "py -m pip install X" works without any PATH modification on
>> all Windows systems with the launcher installed (I can't recall if
>> it's included with Python 2.7 - but if not, maybe it should be
>> backported? There's a standalone version people can get as well).
>
>
> While the discussion to try and get UNIX to adopt `py`  is nice, I think
> that decision falls under python-dev's jurisdiction. So if people here
> decide "we should be pushing for that" then that's great, but that means
> someone needs to go to python-dev and say "distutils-sig is trying to solve
> the issue of `pip` being ambiguous as to what Python installation it works
> with and we thought making `py` a thing on UNIX was the best solution
> forward for `py -m pip`". And if that's the case then the stop-gap is
> `python -m pip`.

That particular discussion would (and did) start on the new linux-sig list :)

To be honest, it didn't gain much traction, but converting
/usr/bin/python to a launcher seems to be a relatively plausible way
of helping to address the 2->3 transition problem (although the
semantics would differ significantly from those of the Windows "py"
launcher).

That would leave "py" continuing to exist indefinitely as a tool
primarily for handling Windows file associations by bringing shebang
line parsing to Windows rather than for direct invocation of the
Python interpreter.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Thu, Nov 12, 2015 at 6:09 PM, Chris Barker - NOAA Federal
 wrote:
>  > If we waved our hands and were able to magically make Python package
>> management perfect, what would that look like?
>
> well, I think the command would be:
>
> python install package_name
>
> I know there are good reasons to keep package installer development out of
> core, but if have ensurepip-- we could do this.

1) What about 'pip uninstall', 'pip freeze', 'pip list', 'pip show',
'pip search', 'pip wheel'?
2) If it requires python 3.6 it's kinda a non-starter...

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Chris Barker - NOAA Federal]

 > If we waved our hands and were able to magically make Python package
> management perfect, what would that look like?

well, I think the command would be:

python install package_name

I know there are good reasons to keep package installer development out of
core, but if have ensurepip-- we could do this.

CHB

Would that kind of discussion even be valuable?

On Tue, Nov 10, 2015, 6:22 PM Nathaniel Smith  wrote:


I totally get why people dislike the ergonomics of 'python -m pip',
but we can also acknowledge that it does solve a real technical
problem: it strictly reduces the number of things that can go wrong,
in a tool that's down at the base of the stack.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Brett Cannon]

On Wed, 11 Nov 2015 at 04:06 Paul Moore  wrote:

> On 11 November 2015 at 06:35, Nick Coghlan  wrote:
> > Windows Python 2 installations require manual PATH modifications
> > regardless, but it's more common for people to know how to make
> > "python -m pip install X" work, than it is for them to remember to
> > also add the "Scripts" directory needed to make "pip install X" work.
>
> ... and "py -m pip install X" works without any PATH modification on
> all Windows systems with the launcher installed (I can't recall if
> it's included with Python 2.7 - but if not, maybe it should be
> backported? There's a standalone version people can get as well).
>

While the discussion to try and get UNIX to adopt `py`  is nice, I think
that decision falls under python-dev's jurisdiction. So if people here
decide "we should be pushing for that" then that's great, but that means
someone needs to go to python-dev and say "distutils-sig is trying to solve
the issue of `pip` being ambiguous as to what Python installation it works
with and we thought making `py` a thing on UNIX was the best solution
forward for `py -m pip`". And if that's the case then the stop-gap is
`python -m pip`.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Oscar Benjamin]

On 11 November 2015 at 06:35, Nick Coghlan  wrote:
>
> Longer term, it may even make sense to take the "python" command on
> *nix systems in that direction, or, at the very least, make "py" a
> cross-platform invocation technique:
> https://mail.python.org/pipermail/linux-sig/2015-October/00.html

This would also be good. The inconsistency between Windows and
everything else is just annoying here. I've never been able to
recommend the use of py.exe even though most of my students are on
Windows and the lab machines are Windows because many of them use OSX
and a few use Linux.

Also although I can reliably assume that "python" is on PATH I can't
know what version it is since it is most likely 3.x on Windows and 2.x
on everything else which means that every script I give them has to be
2/3 compatible. With py.exe I could recommend "py -3" or I guess "py
somescript.py" would throw a helpful error if the shebang doesn't
match (which would be good).

--
Oscar
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 11, 2015 at 9:34:41 AM, Nick Coghlan (ncogh...@gmail.com) wrote:
> On 11 November 2015 at 15:08, Wayne Werner wrote:
> >
> > With all of the weirdness involved, it makes me wonder - could there be a
> > better way? If we waved our hands and were able to magically make Python
> > package management perfect, what would that look like?
> >
> > Would that kind of discussion even be valuable?
>  
> That's essentially what PEP 426 evolved into - an all-singing
> all-dancing wish list of what *my* dream packaging system would enable
> (especially once you include the "Deferred Features" section). In
> practice, most of that is "nice to have" rather than "absolutely
> essential" though, so we're in the midst of the process:
>  
> 1. Figuring out incremental steps that help us to get from "here" to
> "there" by way of formalising what already exists
> 2. Figuring out which parts of "there" represent needless complexity
> that can just be dropped entirely
>  
> Packaging systems are a uniquely difficult ship to steer (even moreso
> than programming language design), since interoperability is king, and
> you need to cope with legacy versions of both packaging tools *and*
> language runtimes.
>  

Right. I think PEP 426 fell into the same trap that distutils2 fell into. It 
attempted to boil the ocean in one step and the longer it went on the more 
aspirational stuff got layered onto it because it was being held up as the 
great hope for packaging.

I think the lessons we’ve learned is that careful [1] incremental improvements 
is the best way forward. It’s a lot easier to reason and handle a small change 
than it is to handle a massive change.

The other important lesson is that one of our ecosystem’s biggest strengths is 
also one of (and probably *the) biggest things holding us back from a large 
re-envisioning. We have a massive number of available packages that have 
accumulated over like two decades. There are half a million individual 
installable package files on PyPI and who knows how many in private 
repositories all around the world. The most ideal system in the world isn’t 
actually useful if it requires throwing out the entire existing ecosystem.

[1] Ones which don’t back us into corners as far as what path we are forced to 
go down into and which don’t add unneeded things because they would be “cool”. 
The Zen of Python has a great section on this, "Now is better than never, 
Although never is often better than *right* now.”.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 11 November 2015 at 14:48, Donald Stufft  wrote:
> Right. I think PEP 426 fell into the same trap that distutils2 fell into. It 
> attempted to boil the ocean in one step and the longer it went on the more 
> aspirational stuff got layered onto it because it was being held up as the 
> great hope for packaging.

Yeah. We really should have seen that happening - when people start
using "Metadata 2.0" as a shorthand for "we're working on it", but
there are no actual changes being delivered, that's a bad sign.

Just shows how hard it is, even when we *know* the issue from bitter
experience, to avoid falling into the same old trap.

People like Nathaniel popping up and saying "look, let's just solve
this one piece of the puzzle right now" are a great catalyst for
getting us out of that rut. (Even if "... never is often better than
*right* now" :-)

> I think the lessons we’ve learned is that careful [1] incremental 
> improvements is the best way forward. It’s a lot easier to reason and handle 
> a small change than it is to handle a massive change.

Agreed. We work best when we're alternating between phases of
incrementally adding new functionality, re-stabilising after change,
and paying off technical debt. Changes that are too big disrupt that
rhythm.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 11 November 2015 at 06:35, Nick Coghlan  wrote:
> Windows Python 2 installations require manual PATH modifications
> regardless, but it's more common for people to know how to make
> "python -m pip install X" work, than it is for them to remember to
> also add the "Scripts" directory needed to make "pip install X" work.

... and "py -m pip install X" works without any PATH modification on
all Windows systems with the launcher installed (I can't recall if
it's included with Python 2.7 - but if not, maybe it should be
backported? There's a standalone version people can get as well).

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nick Coghlan]

On 11 November 2015 at 15:08, Wayne Werner  wrote:
>
> With all of the weirdness involved, it makes me wonder - could there be a
> better way? If we waved our hands and were able to magically make Python
> package management perfect, what would that look like?
>
> Would that kind of discussion even be valuable?

That's essentially what PEP 426 evolved into - an all-singing
all-dancing wish list of what *my* dream packaging system would enable
(especially once you include the "Deferred Features" section). In
practice, most of that is "nice to have" rather than "absolutely
essential" though, so we're in the midst of the process:

1. Figuring out incremental steps that help us to get from "here" to
"there" by way of formalising what already exists
2. Figuring out which parts of "there" represent needless complexity
that can just be dropped entirely

Packaging systems are a uniquely difficult ship to steer (even moreso
than programming language design), since interoperability is king, and
you need to cope with legacy versions of both packaging tools *and*
language runtimes.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Wes Turner]

On Nov 10, 2015 11:09 PM, "Wayne Werner"  wrote:
>
>
> With all of the weirdness involved, it makes me wonder - could there be a
better way? If we waved our hands and were able to magically make Python
package management perfect, what would that look like?
>
> Would that kind of discussion even be valuable?

e.g. re-specifying the mission, goals, and objectives of PyPA?

or e.g. creating a set of numbered user stories / specification
requirements?

"[Users] can [...] (in order to [...] (thus [saving\gaining] [resource
xyz]))"

* Users can install packages from a package index IOT:
  * share code: sdist
  * share binaries: save build time,

* Users can specify (python) package dependencies

* [ ] Users can specify (platform) package (build) dependencies
  * e.g. libssl-dev
  * conda does not solve for this either

* [ ] Users can link between built packages and source VCS revisions with
URIs
  * platform-rev / rev-platform
  * **diff**

>
> On Tue, Nov 10, 2015, 6:22 PM Nathaniel Smith  wrote:
>
>
>> I totally get why people dislike the ergonomics of 'python -m pip',
>> but we can also acknowledge that it does solve a real technical
>> problem: it strictly reduces the number of things that can go wrong,
>> in a tool that's down at the base of the stack.
>
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Robert Collins]

On 12 November 2015 at 03:48, Donald Stufft  wrote:
...
> Right. I think PEP 426 fell into the same trap that distutils2 fell into. It 
> attempted to boil the ocean in one step and the longer it went on the more 
> aspirational stuff got layered onto it because it was being held up as the 
> great hope for packaging.

>From my blog post:
https://rbtcollins.wordpress.com/2015/08/04/the-merits-of-careful-impatience/

"""
So here is how I think we should deliver things instead:

1. Design the change with specific care that it fails closed and is opt-in.
2. Implement the change(s) needed, in a new minor version of the tools.
3. Tell users they can use it.
"""

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[James Bennett]

On Mon, Nov 9, 2015 at 3:41 PM, Chris Barker  wrote:

> pip is a special case -- for MOST python command line tools, the user does
> not care which python it is running with -- if it works, it works.
>
> the failure case we are trying to address here is when "pip install" works
> sjtu fine -- it finds and installs the package into the python pip is
> associated with -- it just doesn't do what the user wants and expects!
>

I still feel like it's just kicking the problem down the line. Switching
from 'pip install' to 'python -m pip install' doesn't actually solve the
issue of how easy we've made it for people to create non-functional Python
installations (non-functional in the sense that they will mysteriously
"work but not really work"). All this switch does is hand the problem over
to the *next* tool the user happens to invoke. So "pip is special" doesn't
really work as a rebuttal, at least to me.

The real problem to solve is management of multi-Python installations; I
don't really know right now *how* to solve it, but slapping one band-aid
onto the problem by changing pip won't accomplish that and so will break a
lot of existing conventions and documentation for what seems like at best
very minor gains.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Chris Barker - NOAA Federal]

> In this situation, if pip's default for finding the python environment
> were to search the path for 'python' instead of using sys.executable,

One trick here -- PATH may not be the same everywhere. For instance,
on OS-X, the environment GUI programs get is entirely independent of
the shell. So, as a rule, PATH will not be "right". I don't know if
anyone tries to run pip from an IDE, but it might be worth keeping in
mind-- this issue comes up all the time with setting the Python used
by an IDE.

-CHB
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Tue, Nov 10, 2015 at 3:29 PM, James Bennett  wrote:
> On Mon, Nov 9, 2015 at 3:41 PM, Chris Barker  wrote:
>>
>> pip is a special case -- for MOST python command line tools, the user does
>> not care which python it is running with -- if it works, it works.
>>
>> the failure case we are trying to address here is when "pip install" works
>> sjtu fine -- it finds and installs the package into the python pip is
>> associated with -- it just doesn't do what the user wants and expects!
>
>
> I still feel like it's just kicking the problem down the line. Switching
> from 'pip install' to 'python -m pip install' doesn't actually solve the
> issue of how easy we've made it for people to create non-functional Python
> installations (non-functional in the sense that they will mysteriously "work
> but not really work"). All this switch does is hand the problem over to the
> *next* tool the user happens to invoke. So "pip is special" doesn't really
> work as a rebuttal, at least to me.

There are lots of ways that Python installations can be broken. As
another example, I helped someone today whose bug report turned out to
boil down to: they used 'pip install' to upgrade a package, and got
upgraded .py files, but somehow their old .pyc files were still around
and in use, so they were still seeing bugs from the old version. The
solution was to manually delete all the .pyc files [1]. No idea how
they managed that, it has nothing to do with this thread, it's just an
example of how infinitely weird installation/configuration problems
get out at the long tail. Python's installed base is large enough that
one-in-a-million cases happen every day...

What's special about pip is that it totally violates DRY: for a
functional python installation, each way of spawning a python
interpreter needs to have a corresponding stub script to spawn pip,
and the shebang line of that stub script has to point to the
corresponding python interpreter. If any part of this complex
assemblage gets out of sync or missing, then your installation is
broken.

(Very few tools have this kind of consistency requirement, because
very few tools are as tightly tied to a single python environment as
pip is -- who cares which virtualenv hg runs out of, it does the same
thing either way. Also, if you do discover that some virtualenv is
missing a script that it should have, then the way to fix that is...
run pip. Kinda a problem if the missing script *is* pip.)

I totally get why people dislike the ergonomics of 'python -m pip',
but we can also acknowledge that it does solve a real technical
problem: it strictly reduces the number of things that can go wrong,
in a tool that's down at the base of the stack.

-n

[1] https://groups.google.com/d/msg/pystatsmodels/KcSzNqDxv-Q/CCim-Tz_BwAJ

-- 
Nathaniel J. Smith -- http://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nick Coghlan]

On 10 November 2015 at 09:24, Chris Barker  wrote:
> As it happens, I am in the middle of a intro class that's using python3.4 or
> 3.5 right now -- and I am telling everyone to do:
>
> python3 -m pip install
>
> Yes, plain old "pip install" is nicer, but only a little bit, and the
> biggest reason we really, really want that to still work is that there are a
> LOT of instructions all over the web telling people to do that -- so really
> too bad if it doesn't work! But the reality is that it often DOESN'T work
> now! and when it doesn't newbies really have no idea why in the heck not!
>
> personally, I think the best approach is to deprecate plain old "pip
> install" -- if it's not there as an option, I expect no one will find it odd
> that to install something for python, you might use python to do that!

Long thread, so I'm picking a semi-random spot to chime in, rather
than replying to every part individually. I think there are a few
different aspects worth considering here:

1. The ergonomics of "pip install X" are really nice, it's by far the
most common instruction given in project documentation, and we're
still in the process of updating documentation to recommend it over
"easy_install X" (or sometimes even over running "./setup.py install"
directly). We *want* it to be the right answer for installing Python
packages, especially in single-installation scenarios.


2. There's one particular reason I *didn't* specify it as the default
recommendation in https://docs.python.org/3/installing/: until Python
3.5, the "pip" executable wasn't placed on the PATH on Windows by
default, even if you'd enabled PATH modification when installing
Python (the problem is that the installers for Python 3.3 and 3.4 only
add the directory where CPython itself resides to PATH, but not the
Scripts directory where "pip.exe" ends up, while even earlier versions
didn't offer the option to modify PATH automatically at all)

So that meant "python -m pip" gave me the broadest coverage - it
worked for everything except system level Python 3 installation on
*nix systems.

With the path issue being fixed in Python 3.5, we're now in the
situation where "pip install X" based instructions will work in all of
the following "single installation" scenarios:

- any activated virtual environment (including conda ones)
- Windows Python 3.5+ installations (with PATH modification selected
at install time)
- *nix Python 2 installations (including Mac OS X and Linux)

"pip install X" still doesn't work for system Python 3 installations
on *nix systems - you need "pip3 install X" or "python3 -m pip install
X" there

Windows Python 2 installations require manual PATH modifications
regardless, but it's more common for people to know how to make
"python -m pip install X" work, than it is for them to remember to
also add the "Scripts" directory needed to make "pip install X" work.


3. I've started thinking of pip as a "plugin manager" for Python. This
is mostly a consequence of work, since many of the challenges we face
in dealing with language specific package management systems are akin
to the ones we encounter with the plugin management systems in web
browsers and IDEs like Eclipse. (It also helps to more clearly
differentiate it from conda, which has the much broader role of being
a data analysis environment manager)

The problem with pip in its current form for that role is that it's
installed as a standalone tool, but isn't natively multi-version
aware. Accordingly, the ideas I like the most are the ones that
suggest taking it down the path of the "py" launcher - make it
natively multi-version aware, and have it choose a well-defined
default target version if multiple versions are available.

Longer term, it may even make sense to take the "python" command on
*nix systems in that direction, or, at the very least, make "py" a
cross-platform invocation technique:
https://mail.python.org/pipermail/linux-sig/2015-October/00.html

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Wayne Werner]

With all of the weirdness involved, it makes me wonder - could there be a
better way? If we waved our hands and were able to magically make Python
package management perfect, what would that look like?

Would that kind of discussion even be valuable?

On Tue, Nov 10, 2015, 6:22 PM Nathaniel Smith  wrote:


I totally get why people dislike the ergonomics of 'python -m pip',
but we can also acknowledge that it does solve a real technical
problem: it strictly reduces the number of things that can go wrong,
in a tool that's down at the base of the stack.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 9, 2015 at 6:17:41 AM, Oscar Benjamin (oscar.j.benja...@gmail.com) 
wrote:
> On 9 November 2015 at 10:44, Wolfgang Maier
> wrote:
> >
> > Something I miss in all the discussions taking place here is the fact that
> > python -m pip is the officially documented way of invoking pip at
> > https://docs.python.org/3/installing/index.html#basic-usage and it is not
> > particularly helpful if that recommendation keeps changing back and forth.
> >
> > I know some people don't like the wordy invocation, but other people
> > (including me) use and teach it because it works reliably. Just because a
> > pip executable based invocation pattern looks better, I don't think it
> > justifies the change.
>  
> I also teach this invocation. Somehow you have to select the Python
> version you're interested in and I really don't see why
>  
> $ pip -p ./foo/bar/python ...
>  
> is better than
>  
> $ ./foo/bar/python -m pip ...
>  
> I already need to explain to students how to ensure that their Python
> executable is on PATH. Needing pip to be on PATH as well is just
> another possible source of confusion (even if there's only one Python
> installation).
>  

The primary difference is one of verbosity, particularly in common cases. 
You’ll have situations like:

* I don’t care what version of Python something is being installed into, I just 
want to install it to use the CLI of some project that just happens to be 
written in python. ``pip install`` vs ``python -m pip install``.
* I’ve already selected which version of Python should be used either via 
virtual environment, conda environment, or some other environment manager. 
``pip install`` vs ``python -m pip install``.
* I just want to install into the same thing as ``python3`` or ``python2`` or 
``python3.3``. ``pip -3 install`` vs ``python3 -m pip install`` or ``pip -2 
install`` vs ``python2 -m pip install`` or ``pip -3.3 install`` vs ``python3.3 
-m pip install``.
* I want to install into ``pypy``. ``pip -p peppy install`` vs ``pypy -m pip 
install``.
* I want to install into ``./foo/bar/python``. ``pip -p ./foo/bar/python 
install`` vs ./foo/bar/python -m pip install``.

I think the main thing this illustrates is that the ``pip -p`` version is nicer 
in the common scenarios like not caring what version of Python you’re 
installing into, having pre-selected the version of Python, or just wanting to 
install into a particular CPython of X or X.Y version [1]. It only really 
degrades into an equivalent invocation in the less common cases where you need 
to install into a non CPython interpreter or your interpreter isn’t one of 
``pythonX`` or ``pythonX.Y`` on your path.

Of course, the main benefit of ``python -m`` is that it’s a standard (within 
Python) interface and it already works and doesn’t require any backwards 
incompatibilities (except to possibly remove the ``pip`` or ``pipX.Y`` commands 
due to their footman-ish nature). It also delays the need to ensure that the 
distutils bindir is on $PATH (though you’ll quickly need to ensure it’s there 
anyways if you install anything that doesn’t use ``-m`` to be invoked).

[1] This could be made better by shipping a ``py`` launcher on *nix too, which 
brings it down to ``py -3 -m pip`` which is still a bit longer than ``pip -3`` 
but is better than ``python3 -m pip``.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Antoine Pitrou]

On Mon, 9 Nov 2015 12:01:37 +
Paul Moore  wrote:
> 
> The one thing that *is* special about pip is that it actually
> *modifies* the Python installation it runs under.

Fortunately, though, if you are running the system pip without having
root privileges activated, it will most certainly fail with a
permission error.

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Wayne Werner]

On Mon, Nov 9, 2015 at 6:01 AM, Paul Moore  wrote:

>
> The one thing that *is* special about pip is that it actually
> *modifies* the Python installation it runs under. So running pip with
> the "wrong" Python makes persistent changes somewhere you weren't
> expecting. Whereas running the wrong Django presumably just fires up a
> website you weren't expecting, which is easily fixed. That makes the
> issues with wrapper commands and PATH more pressing for pip than for
> other projects.
>
> (But I suspect, for example, that IPython may well encounter similar
> issues, if I run the "wrong" IPython wrapper it could start up my
> notebook using the wrong Python interpreter.)


My experience(s) with the latest IPython is that it's freaking magic - in
a good way :)

And by that, I mean when I've had a venv activated it says something
to the effect of, "Hey, we noticed that you're running inside of a virtual
environment so we've taken the pains to activate that for you. Sure,
we're the system installed IPython, but we've done a bit of fiddling so
there's an off chance that things go sideways on you. If that's the case,
you may want to invoke ipython with this other incantation to stop this
behavior".

Of course, I've not had any problems with it's magic default behavior,
so that's a nice thing. But presumably it does the same sort of thing
we're talking about wanting pip to do, vs. `python -m pip`.

-W
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 9, 2015 at 8:26:50 AM, Paul Moore (p.f.mo...@gmail.com) wrote:
> On 9 November 2015 at 12:46, Wayne Werner wrote:
> > My experience(s) with the latest IPython is that it's freaking magic - in
> > a good way :)
>  
> Nice :-) Maybe pip could learn something useful from how the IPython
> guys do that.
> Paul

It’s not likely to be a great option. It essentially just takes 
/usr/bin/ipython and if the ``VIRTUAL_ENV`` variable is defined it munges 
sys.path so that it also adds the ``site-packages`` from the virtual 
environment. This means that it totally ignores —no-site-packages because the 
“outside” Python sys.path is still there.

The ``-p`` flag in my PoC works by munging the sys.path, but the difference is 
that it’s adding something like /usr/bin/pip to the sys.path (which is a zip 
file) which doesn’t otherwise pollute the sys.path with other random crap from 
within the site-packages. It’d be trivial to have the ``-p`` flag default to 
something that just automatically takes into account a virtual environment 
though and python -m pip would implicitly automatically take a virtual 
environment into account.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 9, 2015 at 7:01:57 AM, Paul Moore (p.f.mo...@gmail.com) wrote:
>  
> This is pretty much why I said earlier that this isn't really a pip
> issue. It applies just as much to Django, to pydoc, etc.
>  
> I'm concerned that what is happening at the moment is that every
> project implements its own workaround for the issues with wrapper
> commands and PATH. Either that or most projects simply ignore the
> issue (after all, 99% of projects aren't installed and used in quite
> as many of a user's Python installations as pip is).

I don’t think every project is going to implement it’s own work around because 
I don’t think the problems even affect most projects. For instance, the 
``django-admin`` command isn’t (typically) going to matter which particular 
Python is invoking it. For most people the only time they ever invoke 
``django-admin`` is when they are creating a new project which the particular 
version of Python you’re using to invoke Django doesn’t really matter for that. 
Beyond that they tend to use ./manage.py which has a shebang at that top that 
they can use to adjust which version of Python is being used.

You also have things like tox, twine, virtualenv, invoke, pypi-cli, supervisor, 
vanity, awscli, Carbon/Graphite, etc which are written in Python but the fact 
that they are is basically an implementation detail and what version of Python 
is executing them simply doesn’t matter at all.

I believe that the vast majority of cases where a Python project comes with a 
CLI, the particular version of Python that is being used to *invoke* that CLI 
is typically unimportant, or if it is important is only important in edge 
cases. This makes it obviously the right thing to just use ``mycoolcli`` as the 
standard command, and maybe have a ``python -m mycoolcli`` for the weird edge 
cases.

Projects like pip (and yes IPython too) care a lot about what version of Python 
is invoking them (or more specifically what version of Python they are 
targeting, which is currently controlled by inspecting sys.executable). I 
believe that these projects are the odd ones out because I’m having a problem 
even naming many of them at all and of the ones I can think of they are mostly 
aimed at Python developers vs being something that even people who don’t care 
about Python at all might be using.

The other thing that’s different about pip is just the fact that it’s a project 
that is basically installed into every single Python environment and will be 
used to “target” every single one of those Python environments. I think it’s 
very unusual for someone to have a Python environment where they aren’t using 
pip to install at least something into that environment.

The default now is to install pip into every environment (virtual or real) 
which means that a lot of people will have a great many number of pips 
installed into a variety of environments. Someone who uses Django a lot might 
also have Django installed a lot into many environments, but a primary 
difference there is Django is going to (typically) be something that is 
foremost in that person’s mind about what version they are going to be using. 
However pip is an incidental thing, people don’t typically think about what 
version of pip they have, they just sort of use whatever is there.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 9 November 2015 at 12:46, Wayne Werner  wrote:
> My experience(s) with the latest IPython is that it's freaking magic - in
> a good way :)

Nice :-) Maybe pip could learn something useful from how the IPython
guys do that.
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Mon, Nov 9, 2015 at 5:20 PM, Ionel Cristian Mărieș
 wrote:
>
> On Tue, Nov 10, 2015 at 3:05 AM, Nathaniel Smith  wrote:
>>
>> So apparently if you use 'python -m venv' to create a new *venv* while
>> inside a *virtualenv*, then it seems to complete successfully but
>> leaves you with a venv that doesn't contain pip. At least on my
>> machine (up-to-date Debian testing).
>
>
> How is this relevant? Are you trying to suggest that `pip -p path/to/python`
> would exhibit the same class of bugs and failures `virtualenv -p
> path/to/python` has?

Uh... no, no idea what that even means. It was just intended as an
example of how it's possible to end up in weird situations where 'pip'
and 'python' mean different things, even though I seemingly did
everything right. Evidence for Chris's assertion that "This really
does happend with newbies, and it really is a problem, trust me on
that.". (And maybe a small cry for help, since this really did bite me
just now.)

In this situation, if pip's default for finding the python environment
were to search the path for 'python' instead of using sys.executable,
then it wouldn't matter whether pip were installed into the venv or
not, it would have automatically targeted the active environment. And
'python -m pip' would at least have failed cleanly with a sensible
error message. Current pip just silently targets the wrong
environment.

> I'm not saying it wouldn't but how much of that `no pip in venv` bug is a
> virtualenv issue or a problem with the design of a pip launcher or
> standalone pip? It seems to me that it's a bit irrelevant, but correct me if
> you're not using Ubuntu (were venv is broken in ludicrous ways). Plus
> virtualenv is broken in it's own way (bootstrapping, see this and this) ...

I'm using Debian, as noted in the text you quoted :-). No idea if
Debian's venv is also broken in ludicrous ways (though I wouldn't be
shocked if you told me it was -- I love Debian but I know their Python
team<->distutils communication is not always the greatest...)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Oscar Benjamin]

On 9 November 2015 at 10:44, Wolfgang Maier
 wrote:
>
> Something I miss in all the discussions taking place here is the fact that
> python -m pip is the officially documented way of invoking pip at
> https://docs.python.org/3/installing/index.html#basic-usage and it is not
> particularly helpful if that recommendation keeps changing back and forth.
>
> I know some people don't like the wordy invocation, but other people
> (including me) use and teach it because it works reliably. Just because a
> pip executable based invocation pattern looks better, I don't think it
> justifies the change.

I also teach this invocation. Somehow you have to select the Python
version you're interested in and I really don't see why

$ pip -p ./foo/bar/python ...

is better than

$ ./foo/bar/python -m pip ...

I already need to explain to students how to ensure that their Python
executable is on PATH. Needing pip to be on PATH as well is just
another possible source of confusion (even if there's only one Python
installation).

--
Oscar
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[James Bennett]

On Sunday, November 8, 2015, Ben Finney  wrote:
>
> +1. Addressing this by insisting on ‘python -m foo’ is not a solution.
> It's a plaster over a problem that will remain until the underlying
> conflict is resolved.
>
> That's not to say PyPA should ignore the issue, certainly there are
> things that can be done to help. But ‘python -m foo’ is an ugly wart,
> and I really want the rhetoric to acknowledge that instead of
> considering it a satisfactory end point.
>

I agree with this, and with the feeling that we're just kicking the failure
down the line: if someone doesn't know what Python is being invoked by
'pip', they likely will have the same problem with other tools, too, and
ultimately the ability to run Python scripts directly and without having to
do hackery with supporting/requiring 'python -m' or similar is too useful
and commonly used. So faced with either (essentially) forcing a trend of
every command-line tool having to be invoked with 'python -m', or requiring
people with complex multi-Python installations to be more careful, I choose
the "be more careful" option (i.e., I would strenuously resist changing
Django's admin script to "python -m django" if this were proposed to Django
today).
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Wolfgang Maier]

On 09.11.2015 02:13, Donald Stufft wrote:

On November 5, 2015 at 4:08:56 PM, Donald Stufft (don...@stufft.io) wrote:


Another possible option is to modify pip so that instead of installing into
site-packages we instead create an "executable zip file" which is a simple zip
file that has all of pip inside of it and a top level __main__.py. Python can
directly execute this as if it were installed. We would no longer have any
command except for ``pip`` (which is really this executable zip file). This
script would default to installing into ``python``, and you can direct it to
install into a different python using a (new) flag of ``-p`` or ``--python``
where you can specify either a full path or a command that we'll search $PATH
for.



I’ve implemented a proof of concept of this which can be found at 
https://github.com/pypa/pip/pull/3234. It’s quick and dirty so probably will 
break down in edge cases. I also know it currently doesn’t generate a 
``pip.exe`` on Windows, so if someone runs it on Windows they’ll need to 
execute it as ``python path/to/Scripts/pip``.

I’ve not tested trying to install it via wheel or even installing it via pip, 
so you’ll want to check out the branch or download a tarball and run ``python 
setup.py install`` (or you can run ``python setup.py build`` and just execute 
``build/script-X.Y/pip``).

You might see errors if you don’t build it in a clean virtual environment. 
That’s just because I haven’t bothered to try and isolate the build by default 
yet.



From your comments on the PR:

> - We could possibly restore python -m pip and import pip with a
>   sufficiently magical .pth file installed into site-packages.

Something like this should be done.
I like the idea to have just one pip installed, but I really wouldn't 
like python -m pip to disappear.


Something I miss in all the discussions taking place here is the fact 
that python -m pip is the officially documented way of invoking pip at 
https://docs.python.org/3/installing/index.html#basic-usage and it is 
not particularly helpful if that recommendation keeps changing back and 
forth.


I know some people don't like the wordy invocation, but other people 
(including me) use and teach it because it works reliably. Just because 
a pip executable based invocation pattern looks better, I don't think it 
justifies the change.



> - We could add some short hands inspired by py.exe with things like
> -2, -3, 3.4, etc that will translate to -ppython2, -ppython3,
> -ppython3.4, etc.

Sure, but this extra-effort will be needed just to re-enable something 
that is already possible now via py -m pip.


Your .pth file idea makes me wonder whether an alternative solution 
could be to share one regular pip installation between Python versions 
that way.
Basically, ensurepip and get-pip.py could default to installing pip 
(possibly as an executable zip file) into a separate folder and add a 
.pth file to the sys.executable's site-packages. Later invocations of 
ensurepip/get-pip.py through a different Python could then detect 
presence of pip in its folder and simply add the .pth file to the 
current site-packages.


This would solve the issue of having to manage multiple installations of 
pip, but preserve all current usage patterns (invocation as executable, 
python -m pip, import pip).



> - If we drop say, Python 2.6 and someone wants to install an older
>   version, we might have to make it possible to override the name or
>   something (python setup.py install --script-suffix 2.6?) to enable
>   that particular special case to still work. This would only be
>   needed really when altinstall'ing multiple Pythons into the same
>   bin dir when one or more of those Pythons are not supported by the
>   "main" version of pip you're using.

Yes, but such cases will occur more often as new Python versions are 
released and you drop support for old ones. Effectively, any developer 
who wants to support older versions of Python than the latest pip 
supports will face the problem of explaining users what to do. So 
something really convincing needs to be worked out here.



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Chris Barker]

On Mon, Nov 9, 2015 at 3:27 AM, James Bennett  wrote:

> Python scripts directly and without having to do hackery with
> supporting/requiring 'python -m' or similar is too useful and commonly
> used. So faced with either (essentially) forcing a trend of every
> command-line tool having to be invoked with 'python -m',
>

pip is a special case -- for MOST python command line tools, the user does
not care which python it is running with -- if it works, it works.

the failure case we are trying to address here is when "pip install" works
sjtu fine -- it finds and installs the package into the python pip is
associated with -- it just doesn't do what the user wants and expects!

any other script can be run with any python that will work -- if a user has
ten different versions of python installed, and every different python-bsed
tool they use uses a different one -- who cares, as long as it works.

or requiring people with complex multi-Python installations to be more
> careful, I choose the "be more careful" option (i.e., I would strenuously
> resist changing Django's admin script to "python -m django" if this were
> proposed to Django today).
>

Well, the exception to the above is people developing those scripts, but
they should know better -- and so should a sysadmin instaling a django app.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Chris Barker]

wow! a really long thread here. Trying not to duplicate too much. I am
coming primarily from the perspective of someone that teaches python to
beginners (I'm also a user and package developer, but I, myself, can deal
with any of these options...)

My perspective as a user of pip, but not a developer, is that having the
> command line executable `pip` is much preferable to `python -m pip`. Most
> of the use cases that militate against the command line executable seem to
> be issues that face developers and ultra-power-users (keeping track of many
> versions of pip installed, etc).
>

This is absolutely not true -- the ultra-power-users (am I one of those? --
cool! I need to find a good use for that ultra power!) understand these
complexities and can deal with them.

the real losers ar newbies that have, for one reason or another, multiple
pythons on their system. Both Linux and OS-Z tend to have system installed
pythons, and it is very, very common that a user needs (maybe for a class,
or ...) to install a different one when they are still rank beginners.
Also, people who are new to python coding have very different backgrounds
with the CLI, and manipulating PATH, and all that. so I think the target
user is someone that is new to both python and CLI use, and also has more
than one version of python in their system.

As it happens, I am in the middle of a intro class that's using python3.4
or 3.5 right now -- and I am telling everyone to do:

python3 -m pip install

Yes, plain old "pip install" is nicer, but only a little bit, and the
biggest reason we really, really want that to still work is that there are
a LOT of instructions all over the web telling people to do that -- so
really too bad if it doesn't work! But the reality is that it often DOESN'T
work now! and when it doesn't newbies really have no idea why in the heck
not!

personally, I think the best approach is to deprecate plain old "pip
install" -- if it's not there as an option, I expect no one will find it
odd that to install something for python, you might use python to do that!

which brings up an idea -- to make it clean, why not really integrate
"ensurepip" into python:

python --install some_package

It will take a long time to propagate through the versions and installs,
but doesn't it make sense that the officially supported package installer
actually be invoked directly from python?

But many casual users, I think, just have one version of python/pip
> installed, and benefit from having the easy-to-call executable.
>

I suppose it's not so bad that in the case of one python, that pip install
just works.

They're also the least capable of adding new script wrappers and bash
> aliases.
>

absolutely --- that should inly be required for us "ultra-power-users" :-)

glyph wrote:


> Rather than trying to figure out what the "right" way for users to invoke
> `pip´ to begin with is, why not just have Pip start providing more
> *information* about potential problems when you invoke it?
>

This is a great idea! we will be stuck with users expecting "pip install"
to work for a long time. If they at least get a helpful hint that something
weird is going on -- that would help a lot. And this wourl require only
changes to pip itself, no changes to documentation the world over.

We should do this in the interim, regardless of other paths forward.

I've lost track of the technical details on the option to have a
self-contained pip executable -- so no comment there.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Chris Barker]

On Sat, Nov 7, 2015 at 3:53 PM, Antoine Pitrou  wrote:

> Well, the problem is that "python -m pip" isn't any better. If you
> don't know what the current "pip" is, then chances are you don't know
> what the current "python" is, either.
>

sure you do (well, maybe not, but all you know is that when you type
"python" you get soemthing).

the problem really is when someone does:

pip install some_package

and it all seems to work fine

then they type "python" and "import some_package" and it fails.


This really does happend with newbies, and it really is a problem, trust me
on that.

granted, it's also a problem that people type "python" and can import what
they want, then they go to run their code in an IDE, and it doesn't work --
but that's not a problem pip can address ..

(I'm not trying to deny the issue, I sometimes wonder what "pip" will
> install into exactly, but removing the command in favour of a "-m"
> switch wouldn't do any any good IMO, and it would make Python package
> management "even more baroque" than it currently is)
>

only minimally more baroque, and at least one large class of confusing
errors would be impossible.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 9 November 2015 at 11:27, James Bennett  wrote:
> I agree with this, and with the feeling that we're just kicking the failure
> down the line: if someone doesn't know what Python is being invoked by
> 'pip', they likely will have the same problem with other tools, too, and
> ultimately the ability to run Python scripts directly and without having to
> do hackery with supporting/requiring 'python -m' or similar is too useful
> and commonly used. So faced with either (essentially) forcing a trend of
> every command-line tool having to be invoked with 'python -m', or requiring
> people with complex multi-Python installations to be more careful, I choose
> the "be more careful" option (i.e., I would strenuously resist changing
> Django's admin script to "python -m django" if this were proposed to Django
> today).

This is pretty much why I said earlier that this isn't really a pip
issue. It applies just as much to Django, to pydoc, etc.

I'm concerned that what is happening at the moment is that every
project implements its own workaround for the issues with wrapper
commands and PATH. Either that or most projects simply ignore the
issue (after all, 99% of projects aren't installed and used in quite
as many of a user's Python installations as pip is).

The one thing that *is* special about pip is that it actually
*modifies* the Python installation it runs under. So running pip with
the "wrong" Python makes persistent changes somewhere you weren't
expecting. Whereas running the wrong Django presumably just fires up a
website you weren't expecting, which is easily fixed. That makes the
issues with wrapper commands and PATH more pressing for pip than for
other projects.

(But I suspect, for example, that IPython may well encounter similar
issues, if I run the "wrong" IPython wrapper it could start up my
notebook using the wrong Python interpreter.)

I'm no closer to having a good suggestion for a solution here, just
trying to point out that by thinking about this from a pip-only
perspective we might be missing better solutions that apply from a
broader perspective.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Antoine Pitrou]

On Mon, 9 Nov 2015 11:16:56 +
Oscar Benjamin  wrote:
> On 9 November 2015 at 10:44, Wolfgang Maier
>  wrote:
> >
> > Something I miss in all the discussions taking place here is the fact that
> > python -m pip is the officially documented way of invoking pip at
> > https://docs.python.org/3/installing/index.html#basic-usage and it is not
> > particularly helpful if that recommendation keeps changing back and forth.
> >
> > I know some people don't like the wordy invocation, but other people
> > (including me) use and teach it because it works reliably. Just because a
> > pip executable based invocation pattern looks better, I don't think it
> > justifies the change.
> 
> I also teach this invocation. Somehow you have to select the Python
> version you're interested in and I really don't see why

"Selecting the Python version you're interested in", in many cases, is
done /a priori/ by activating the appropriate environment (whether
virtualenv-, pyvenv- or conda-based).

When I'm using a conda environment I certainly don't want to type
"python -m pip" when "pip" is sufficient.

It would be nice if people here could acknowledge the diversity of
existing workflows.

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Mon, Nov 9, 2015 at 3:28 PM, Chris Barker  wrote:
> On Sat, Nov 7, 2015 at 3:53 PM, Antoine Pitrou  wrote:
>>
>> Well, the problem is that "python -m pip" isn't any better. If you
>> don't know what the current "pip" is, then chances are you don't know
>> what the current "python" is, either.
>
>
> sure you do (well, maybe not, but all you know is that when you type
> "python" you get soemthing).
>
> the problem really is when someone does:
>
> pip install some_package
>
> and it all seems to work fine
>
> then they type "python" and "import some_package" and it fails.
>
>
> This really does happend with newbies, and it really is a problem, trust me
> on that.

Here's an interesting situation to illustrate the kind of weird
problem that newbies are so good at tripping over:

$ virtualenv -p python3 test-env1
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in test-env1/bin/python3
Also creating executable in test-env1/bin/python
Installing setuptools, pip...done.
$ source test-env1/bin/activate
(test-env1)$ which python
/home/njs/test-env1/bin/python
(test-env1)$ which pip
/home/njs/test-env1/bin/pip

# So far so good... now let's create a second environment from inside the first
(test-env1)$ python -m venv test-env2
(test-env1)$ source test-env2/bin/activate
(test-env2) $ which python
/home/njs/test-env2/bin/python
(test-env2) $ which pip
/usr/bin/pip
(test-env2) $ ls test-env2/bin
activate  activate.csh  activate.fish  python@  python3@
(test-env2) $

So apparently if you use 'python -m venv' to create a new *venv* while
inside a *virtualenv*, then it seems to complete successfully but
leaves you with a venv that doesn't contain pip. At least on my
machine (up-to-date Debian testing).

I'm sure I should file a bug somewhere, but I'm not even sure where...

(Interesting fact: I also tried this but using a conda environment for
the first environment instead of virtualenv, and it failed differently
-- the 'python -m venv' call spat out an inscrutable error involving
ensurepip, and then I was left with a non-functional environment --
the test-env2/ directory exists, as does test-env2/bin/python, but
test-env2/bin/activate is missing entirely.)

This is "just a bug", but it seems fair to assume that there will
continue to exist some weird corner-case bugs in Python
packaging/distribution/environment-creation for a while yet...

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 9, 2015 at 8:05:29 PM, Nathaniel Smith (n...@pobox.com) wrote:
> > This is "just a bug", but it seems fair to assume that there will  
> continue to exist some weird corner-case bugs in Python
> packaging/distribution/environment-creation for a while  
> yet…

Note: I think my PoC will correctly handle all of these cases pretty easily and 
would do it currently with ``-p`` (but by default it uses sys.executable, not 
sure if that makes more sense or if ``python`` does).

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Sun, Nov 8, 2015 at 8:01 AM, Ionel Cristian Mărieș
 wrote:
>
> On Sat, Nov 7, 2015 at 12:24 AM, Donald Stufft  wrote:
>>
>> Well, it’s not really a launcher no, but you’d do ``pip -p python2 install
>> foo`` or something like that. It’s the same UI. Having just a “launcher” I
>> think is actually more confusing (and we already had that in the past with
>> -E and removed it because it was confusing). Since you’ll have different
>> versions of pip in different environments (Python or virtual) things break
>> or act confusingly.
>
>
> That can't be worse than the current situation. And I'm not asking to bring
> `-E` back.
>
> The idea is that the pip bin becomes a launcher file, just like py.exe - it
> would just try to discover an appropiate python and run `-mpip` with it.
> This doesn't even need
>
> to be implemented in pip - linux distributions can do this.

I think it's fair to raise an eyebrow at this, though -- basically the
problem is that pip has a really unusual argument passing convention,
which is that it expects to receive the path to the target python in
sys.executable. So instead of fixing this weird argument passing
convention, we're setting up a shim to take the UI we actually want
("discover an appropriate python"), and converting it to the weird
argument passing convention.

Maybe it's the best approach given the weight of history and so forth,
but we can at least acknowledge that it's pretty weird!

-- 
Nathaniel J. Smith -- http://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Thu, Nov 5, 2015 at 7:52 PM, Glyph Lefkowitz  wrote:
>
> If you invoke 'pip[X.Y]' and it matches 'python -m pip' in your current
> virtualenv, don't say anything; similarly if you invoke 'python -m pip' and
> 'which pip' matches.  But if there's a mismatch, pip can print information
> in both cases.  This would go a long way to alleviating the confusion that
> occurs when users back themselves into one of these corners, and would alert
> users to potential issues before they become a problem; right now you have
> to be a dogged investigative journalist to figure out why pip is doing the
> wrong thing in some cases.

Here's a sketch of how something like this might look:

https://gist.github.com/njsmith/c051a8298cc641bcfef4

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Tue, Nov 10, 2015 at 3:05 AM, Nathaniel Smith  wrote:

> So apparently if you use 'python -m venv' to create a new *venv* while
> inside a *virtualenv*, then it seems to complete successfully but
> leaves you with a venv that doesn't contain pip. At least on my
> machine (up-to-date Debian testing).
>

​How is this relevant? Are you trying to suggest that `pip -p
path/to/python` would​ exhibit the same class of bugs and failures
`virtualenv -p path/to/python` has?

​I'm not saying it wouldn't but​ ​how much of that `no pip in venv`​ bug is
a virtualenv issue or a problem with the design of a pip launcher or
standalone pip? It seems to me that it's a bit irrelevant, but correct me
if you're not using Ubuntu (were venv is broken in ludicrous ways). Plus
virtualenv is broken in it's own way (bootstrapping, see this
 and this
) ...



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Wayne Werner]

On Sat, Nov 7, 2015, 5:41 PM Paul Moore  wrote:

On 7 November 2015 at 22:21, Antoine Pitrou  wrote:
> The actual question is: which problem are you trying to solve *that
> current users are actually experiencing*?

Typically, people using "pip" to install stuff, and finding it gets
installed into the "wrong" Python installation (i.e., not the one they
expected). I'm not clear myself on how this happens, but it seems to
be common on some Linux distros (and I think on OSX as well) where
system and user-installed Pythons get confused.



I've actually stopped using "pip install" in favor of "python -m pip
install" for this very reason. At the very least I know that if my next
command is "python " I'll have those packages installed in that
same python. On windows I used "py -3.4 -m pip".

-W
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Antoine Pitrou]

On Sat, 7 Nov 2015 19:37:03 -0500
Donald Stufft  wrote:
> In fact, the pyvenv script has been deprecated and is going to be
> removed in Python 3.8 in favor of `python -m venv` for similar
> reasons that I've described here.

That's not an argument, since the decision was taken by exactly the
same people. Just because you do something twice doesn't mean it was a
good thing to do, especially when no sizable data was brought in
support.

The fact that you decided to deprecate "pyvenv" while its ancestor - the
"virtualenv" script itself - was not deprecated despite existing for a
much longer time hints that the issue may be blown out of proportion.

In the end, I like "python -m " for many user interfaces;
but for managing package installations I think it's really much too
wordy.

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Sat, Nov 7, 2015 at 12:24 AM, Donald Stufft  wrote:

> Well, it’s not really a launcher no, but you’d do ``pip -p python2 install
> foo`` or something like that. It’s the same UI. Having just a “launcher” I
> think is actually more confusing (and we already had that in the past with
> -E and removed it because it was confusing). Since you’ll have different
> versions of pip in different environments (Python or virtual) things break
> or act confusingly.
>

​That can't be worse than the current situation. And I'm not asking to
bring `-E` back.

The idea is that the pip bin becomes a launcher file, just like py.exe - it
would just try to discover an appropiate python and run `-mpip` with it.
This doesn't even need​

​to be implemented in pip - linux distributions can do this.

For windows it's more tricky - but if Python on windows has getpip ​why
can't it bundle a pip.exe, just like py.exe?

Another issue that is being conflated here is the most frequent scenario:
using virtualenv activation. We should should be really be talking about
deprecating the activation shell scripts - messing with $PATH is what we
should really look at - not deprecating `pip` bin over to the overly
tedious `python -mpip`.




Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 8 November 2015 at 00:37, Donald Stufft  wrote:
> This probably does also affect pydoc but I would suggest that more people are 
> invoking pip in various “weird” situation than are invoking pydoc. I know 
> personally I’ve *never* invoked pydoc. In fact, the pyvenv script has been 
> deprecated and is going to be removed in Python 3.8 in favor of `python -m 
> venv` for similar reasons that I've described here.

It applies to pretty much everything. It's basically why the -m flag
was added to Python. It's not taken off because it's not exactly
ideal, but the alternative is a bit of a mess too (more or less so
depending on your OS, distribution and/or working practices).

Unfortunately, pip is orders of magnitude more frequently used than
the other commands that suffer from this problem, so it *feels* like a
pip issue. But it isn't really, it's either a Python issue or an OS
issue, depending on how you view it.

Java has a very similar issue. The "java -jar myproject.jar" syntax is
basically the same as "python -m". The alternative used in the Java
world is a plethora of Windows batch files and Unix shell scripts,
usually combined with an installation process that goes something like
"here's the driver scripts, work out for yourself how to get them on
your PATH". Plus environment variables to say which is your preferred
Java installation. (Java doesn't have anything like virtual
environments, so actually the problem they face is *simpler* than
Python's).

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 8, 2015 at 9:13:48 AM, Antoine Pitrou (solip...@pitrou.net) wrote:
> On Sat, 7 Nov 2015 19:37:03 -0500
> Donald Stufft wrote:
> > In fact, the pyvenv script has been deprecated and is going to be
> > removed in Python 3.8 in favor of `python -m venv` for similar
> > reasons that I've described here.
>  
> That's not an argument, since the decision was taken by exactly the
> same people. Just because you do something twice doesn't mean it was a
> good thing to do, especially when no sizable data was brought in
> support.
>  
> The fact that you decided to deprecate "pyvenv" while its ancestor - the
> "virtualenv" script itself - was not deprecated despite existing for a
> much longer time hints that the issue may be blown out of proportion.
>  
> In the end, I like "python -m " for many user interfaces;
> but for managing package installations I think it's really much too
> wordy.
>  

U I had nothing to do with deprecating the pyvenv script. Brett Cannon 
suggested it.

The virtualenv script wasn’t deprecated (and I haven’t suggested doing it) 
because the virtualenv script already functions similarly to how I suggested in 
my last option. You aren’t expected to install virtualenv into every Python and 
then invoke the correct one based on which version of Python you want to 
interact with (as pyvenv and pip require you to do). Instead you tell it which 
version of Python you want to interact with using the ``-p`` flag (which 
accepts things like ``python2`` or full paths). So there is no ambiguity about 
which version of Python you’re going to be interacting with. The only thing 
that matters at all for which version of Python virtualenv is installed into is 
that it controls the *default*, but that’s just the default and on some systems 
(like Debian) virtualenv is installed into Python 3.x and the default was 
switched to 2.x still.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ben Finney]

Paul Moore  writes:

> Unfortunately, pip is orders of magnitude more frequently used than
> the other commands that suffer from this problem, so it *feels* like a
> pip issue. But it isn't really, it's either a Python issue or an OS
> issue, depending on how you view it.

+1. Addressing this by insisting on ‘python -m foo’ is not a solution.
It's a plaster over a problem that will remain until the underlying
conflict is resolved.

That's not to say PyPA should ignore the issue, certainly there are
things that can be done to help. But ‘python -m foo’ is an ugly wart,
and I really want the rhetoric to acknowledge that instead of
considering it a satisfactory end point.

-- 
 \“We cannot solve our problems with the same thinking we used |
  `\   when we created them.” —Albert Einstein |
_o__)  |
Ben Finney

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Wolfgang Maier]

On 05.11.2015 22:08, Donald Stufft wrote:


* Having pip need to be installed into each Python means you end up with a
   bunch of independent pip installations which all need to be independently
   updated. We've made this better by having recent pips warn you if you're not
   on the latest version, but it's not unusual for me personally to have 30+
   different installations of pip on my personal desktop. That isn't great.



For the record, it is possible to have just one pip accessed by multiple 
installed Pythons right now.
Just add a .pth file to site-packages of each Python with an entry to 
the same shared directory. Install pip into one Python, then mv the pip 
and the accompanying dist-info folder to that shared directory.
It's a bit of effort to set up the first time, but you'll only have one 
pip to update afterwards.



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 5, 2015 at 4:08:56 PM, Donald Stufft (don...@stufft.io) wrote:
>  
> Another possible option is to modify pip so that instead of installing into
> site-packages we instead create an "executable zip file" which is a simple zip
> file that has all of pip inside of it and a top level __main__.py. Python can
> directly execute this as if it were installed. We would no longer have any
> command except for ``pip`` (which is really this executable zip file). This
> script would default to installing into ``python``, and you can direct it to
> install into a different python using a (new) flag of ``-p`` or ``--python``
> where you can specify either a full path or a command that we'll search $PATH
> for.
>  

I’ve implemented a proof of concept of this which can be found at 
https://github.com/pypa/pip/pull/3234. It’s quick and dirty so probably will 
break down in edge cases. I also know it currently doesn’t generate a 
``pip.exe`` on Windows, so if someone runs it on Windows they’ll need to 
execute it as ``python path/to/Scripts/pip``.

I’ve not tested trying to install it via wheel or even installing it via pip, 
so you’ll want to check out the branch or download a tarball and run ``python 
setup.py install`` (or you can run ``python setup.py build`` and just execute 
``build/script-X.Y/pip``).

You might see errors if you don’t build it in a clean virtual environment. 
That’s just because I haven’t bothered to try and isolate the build by default 
yet.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Antoine Pitrou]

The actual question is: which problem are you trying to solve *that
current users are actually experiencing*?

I'm -1 on removing the "pip" command.  "python -m pip" is frankly not a
reasonable subtitution if we want to *promote* pip.

> * The above gets *really* confusing when ``pipX`` or ``pip`` do not agree with
>   what ``pythonX`` and ``python`` point to.

That's a problem for foreign package managers and distributions. Let
them deal with it.

Regards

Antoine.


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 7 November 2015 at 22:21, Antoine Pitrou  wrote:
> The actual question is: which problem are you trying to solve *that
> current users are actually experiencing*?

Typically, people using "pip" to install stuff, and finding it gets
installed into the "wrong" Python installation (i.e., not the one they
expected). I'm not clear myself on how this happens, but it seems to
be common on some Linux distros (and I think on OSX as well) where
system and user-installed Pythons get confused.

Whether removing the pip command in favour of explicitly using the
name of the python you want to install into is a reasonable solution,
or an over-reaction, is what we're trying to establish. But it is a
very real problem and we see a fair number of bug reports based on it.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Antoine Pitrou]

On Sat, 7 Nov 2015 19:16:55 -0500
Donald Stufft  wrote:
> 
> The largest problem comes when ``python`` and ``pip`` disagree about which 
> Python is being invoked.

As a said, this is a problem for package managers and distributions.
"pip" isn't the only affected command, e.g. "pydoc" is as well.

> What should the command be to install into PyPy 2.4.0?

If you are using a virtualenv (or a conda environment, assuming you
did a conda package for pypy), just "pip".

> What if someone has /usr/bin/python2.7
> and /usr/bin/pip2.7 and they then install another Python 2.7
> into /usr/local/bin/python2.7 but they don’t have pip installed there?

Why wouldn't they? I thought the plan is to have "pip" bundled with
every recent Python version? AFAIR someone even said it was a bug if pip
wasn't installed together with Python...

Regards

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[David Mertz]

I found I really did typically have that problem that Paul describes pretty
often until I switched to using predominantly conda.  I would always make
symlinks for pip2 and pip3 (and maybe for pip3.3 vs. pip3.4) to make sure
things went the right places.

I suppose this problem was largely because I didn't really use virtualenv
much, and now that I'm a conda person the environments come "for free" with
the installation.

On Sat, Nov 7, 2015 at 3:41 PM, Paul Moore  wrote:

> On 7 November 2015 at 22:21, Antoine Pitrou  wrote:
> > The actual question is: which problem are you trying to solve *that
> > current users are actually experiencing*?
>
> Typically, people using "pip" to install stuff, and finding it gets
> installed into the "wrong" Python installation (i.e., not the one they
> expected). I'm not clear myself on how this happens, but it seems to
> be common on some Linux distros (and I think on OSX as well) where
> system and user-installed Pythons get confused.
>
> Whether removing the pip command in favour of explicitly using the
> name of the python you want to install into is a reasonable solution,
> or an over-reaction, is what we're trying to establish. But it is a
> very real problem and we see a fair number of bug reports based on it.
>
> Paul
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
*David Mertz, Ph.D.*
*Senior Software Engineer and Senior Trainer*
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 7, 2015 at 7:12:59 PM, Antoine Pitrou (solip...@pitrou.net) wrote:
> On Sat, 7 Nov 2015 23:41:25 +
> Paul Moore wrote:
> > On 7 November 2015 at 22:21, Antoine Pitrou wrote:
> > > The actual question is: which problem are you trying to solve *that
> > > current users are actually experiencing*?
> >
> > Typically, people using "pip" to install stuff, and finding it gets
> > installed into the "wrong" Python installation (i.e., not the one they
> > expected). I'm not clear myself on how this happens, but it seems to
> > be common on some Linux distros (and I think on OSX as well) where
> > system and user-installed Pythons get confused.
>  
> Well, the problem is that "python -m pip" isn't any better. If you
> don't know what the current "pip" is, then chances are you don't know
> what the current "python" is, either.
>  
> (I'm not trying to deny the issue, I sometimes wonder what "pip" will
> install into exactly, but removing the command in favour of a "-m"
> switch wouldn't do any any good IMO, and it would make Python package
> management "even more baroque" than it currently is)
>  

The largest problem comes when ``python`` and ``pip`` disagree about which 
Python is being invoked. A further problem is that we also need a way beyond 
just X.Y to differentiate what version of Python something is being installed 
into. What should the command be to install into PyPy 2.4.0? What about PyPy3 
2.4.0? What if someone has /usr/bin/python2.7 and /usr/bin/pip2.7 and they then 
install another Python 2.7 into /usr/local/bin/python2.7 but they don’t have 
pip installed there?

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Antoine Pitrou]

On Sat, 7 Nov 2015 23:41:25 +
Paul Moore  wrote:
> On 7 November 2015 at 22:21, Antoine Pitrou  wrote:
> > The actual question is: which problem are you trying to solve *that
> > current users are actually experiencing*?
> 
> Typically, people using "pip" to install stuff, and finding it gets
> installed into the "wrong" Python installation (i.e., not the one they
> expected). I'm not clear myself on how this happens, but it seems to
> be common on some Linux distros (and I think on OSX as well) where
> system and user-installed Pythons get confused.

Well, the problem is that "python -m pip" isn't any better. If you
don't know what the current "pip" is, then chances are you don't know
what the current "python" is, either.

(I'm not trying to deny the issue, I sometimes wonder what "pip" will
install into exactly, but removing the command in favour of a "-m"
switch wouldn't do any any good IMO, and it would make Python package
management "even more baroque" than it currently is)

Regarrds

Antoine.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 7, 2015 at 7:22:23 PM, Antoine Pitrou (solip...@pitrou.net) wrote:
> On Sat, 7 Nov 2015 19:16:55 -0500
> Donald Stufft wrote:
> >
> > The largest problem comes when ``python`` and ``pip`` disagree about which 
> > Python  
> is being invoked.
>  
> As a said, this is a problem for package managers and distributions.
> "pip" isn't the only affected command, e.g. "pydoc" is as well.

Package managers and distributions aren’t the only place that Python comes 
from. People might have installed their own Python (such as via pyenv or even 
manually) or they may be using two different package managers one that comes 
with pip by default and one that doesn’t.

This probably does also affect pydoc but I would suggest that more people are 
invoking pip in various “weird” situation than are invoking pydoc. I know 
personally I’ve *never* invoked pydoc. In fact, the pyvenv script has been 
deprecated and is going to be removed in Python 3.8 in favor of `python -m 
venv` for similar reasons that I've described here.

>  
> > What should the command be to install into PyPy 2.4.0?
>  
> If you are using a virtualenv (or a conda environment, assuming you
> did a conda package for pypy), just "pip”.

And if you’re not using a virtual environment or a conda environment? If you 
have /usr/bin/python and /usr/bin/pypy how should I install something into 
PyPy? We can’t just pretend that the only time someone wants to install into 
PyPy is inside of a virtual environment.

>  
> > What if someone has /usr/bin/python2.7
> > and /usr/bin/pip2.7 and they then install another Python 2.7
> > into /usr/local/bin/python2.7 but they don’t have pip installed there?
>  
> Why wouldn't they? I thought the plan is to have "pip" bundled with
> every recent Python version? AFAIR someone even said it was a bug if pip
> wasn't installed together with Python…

Python 2.7.9+ and Python 3.4+ come with ensurepip which can be used to install 
pip into an environment. In Python 3.4+ it will be installed by default by the 
Makefile and by the OSX/Windows installers. In Python 2.7.9+ it’s only 
installed by default in the OSX/Windows installers but it is not in the 
Makefile. So how might they not get pip?

* They installed from a Makefile (or their distribution did) and they either 
accepted the 2.7 default or they disabled it when installing on 3.4.
* They are using a version of Python that didn’t come with pip.
* They uninstalled pip (because pip isn’t part of the standard library, it’s 
just another Python package that can be uninstalled or upgraded).
* They installed into a virtual environment that was created without pip being 
installed.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Vincent Povirk]

> Typically, people using "pip" to install stuff, and finding it gets
> installed into the "wrong" Python installation (i.e., not the one they
> expected). I'm not clear myself on how this happens, but it seems to
> be common on some Linux distros (and I think on OSX as well) where
> system and user-installed Pythons get confused.

FWIW, the approach I'm taking for the oneget provider is that, if
there's more than one version of python into which you "can" install a
package (the definition of "can install" is a bit hairy, but for right
now it means the versions with wheels if there are any wheels), it'll
print a message listing the installs you can use. You can then specify
an install using -PythonVersion 3.4 or -PythonLocation
c:\python34\python.exe.

The -PythonVersion switch implicitly uses a wildcard compare (3.4.*)
even though the wildcard is not specified.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Thu, Nov 5, 2015 at 1:08 PM, Donald Stufft  wrote:
> Another possible option is to modify pip so that instead of installing into
> site-packages we instead create an "executable zip file" which is a simple zip
> file that has all of pip inside of it and a top level __main__.py. Python can
> directly execute this as if it were installed. We would no longer have any
> command except for ``pip`` (which is really this executable zip file). This
> script would default to installing into ``python``, and you can direct it to
> install into a different python using a (new) flag of ``-p`` or ``--python``
> where you can specify either a full path or a command that we'll search $PATH
> for.

I'm not sure if I like this idea or not, but I think it's an
interesting one. I'd frame it differently, though. It seems to me that
the core idea is:

A basic problem that pip has to solve, before it can do anything else,
is that it has to identify the python environment that it's supposed
to be working on. Right now, the standard way it does this is by
looking at sys.executable -- so pip is always doing an odd dance where
it's rearranging the universe around itself, and conversely, every
environment needs to have its own copy of pip inside itself. An
alternative approach would be to totally decouple the host python used
to execute pip from the target python that pip acts upon, on the
grounds that these are logically distinct things. (As a thought
experiment you can even imagine a package manager called, say, 'cpip',
which is a standalone program written in C or some other
non-Python-language, but that happens to know how to manipulate Python
environments. I'm not saying porting pip to another language makes is
in any way a good idea, just that imagining such a thing is a useful
exercise to clarify the difference between the host environment and
the target environment.) In this approach, you'd have a program called
'pip', and when run it uses some set of rules to figure out which
environment it should work on, consulting command line arguments,
environment variables, the current PATH, whatever.

(Windows has its own complicated system that I don't understand, but
for Unix-likes, the default rule would probably be: search the path
for "python" + sys.argv[0][3:], and use that. So you could install a
main pip executable + symlinks named pip3, pip3.4, etc., and invoking
each of them would automatically target the same environments you get
when you run python, python3, python3.4, etc.)

Having decoupled things like this, then it doesn't really matter how
pip is distributed, so long as there is a pip program and it works.
It'd be in a similar position to, say, how mercurial is shipped. You
could use pyinstaller to make a fully standalone package for Windows
that didn't even depend on the system python install, and Debian could
ship a version that's hosted by the system default python, and if you
want to have multiple pip's installed then you could do that just like
you do now by installing them into their own venvs.

Other interesting consequences:

- pip could get more aggressive about dropping *host* support for
older versions of python -- e.g. eventually pip itself could be
written in pure python 3 while still preserving support for installing
stuff into a python 2 target environment. Or less aggressively, you
could imagine dropping host support for 2.6 ahead of dropping target
support for 2.6.

- If pip is a thing that lives "outside" environments instead of
"inside" them, then it might be natural for it to grow some interface
tools for working with environments directly, becoming kinda the
one-stop-friendly-UI for Python developers. E.g.

   pip new-env my-env/ -p pypy3 -r requirements.txt

to create a new virtual environment and install stuff into it in one
go. (Probably pip is going to have to gain some related functionality
anyway to install setup-requires into isolated build environments...)
Obviously there's a desire not to shove everything in the world into
pip, but having a single friendly frontend to
installation/virtualenv/venv is *really* nice for newbies. And
obviously this would a be "someday maybe" thing at best, just an
interesting possibility down the road.

- The eventual interface seems nice enough...

path/to/python -m pip
-> pip -p path/to/python

pip3, pip3.5
-> still would work in my suggested interface

path/to/venv/bin/pip
-> pip -p path/to/venv/bin/python
or pip -E path/to/venv

though the transition would be tricky/painful.

I don't have any conclusion, I just think it's just an interesting
idea to think about.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[David Mertz]

On Nov 7, 2015 7:30 PM, "Nathaniel Smith"  wrote:
> alternative approach would be to totally decouple the host python used
> to execute pip from the target python that pip acts upon, on the
> grounds that these are logically distinct things. (As a thought
> experiment you can even imagine a package manager called, say, 'cpip',
> which is a standalone program written in C or some other
> non-Python-language, but that happens to know how to manipulate Python
> environments.

This is a great idea! It exists, and it is spelled "conda". Well, it's
written in some particular version of Python, but the package and
environment management is completely decoupled. You can in install R
packages or Julia packages or different Python versions.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Xavier Fernandez]

On Fri, Nov 6, 2015 at 4:52 AM, Glyph Lefkowitz 
wrote:
>
> Rather than trying to figure out what the "right" way for users to invoke
> `pip´ to begin with is, why not just have Pip start providing more
> *information* about potential problems when you invoke it?
>
> If you invoke 'pip[X.Y]' and it matches 'python -m pip' in your current
> virtualenv, don't say anything; similarly if you invoke 'python -m pip' and
> 'which pip' matches.  But if there's a mismatch, pip can print information
> in both cases.  This would go a long way to alleviating the confusion that
> occurs when users back themselves into one of these corners, and would
> alert users to potential issues before they become a problem; right now you
> have to be a dogged investigative journalist to figure out why pip is doing
> the wrong thing in some cases.
>

I like this solution which is easy to implement and should directly help
the user without any deprecation process.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 6 November 2015 at 03:52, Glyph Lefkowitz  wrote:
> If you invoke 'pip[X.Y]' and it matches 'python -m pip' in your current
> virtualenv, don't say anything; similarly if you invoke 'python -m pip' and
> 'which pip' matches.  But if there's a mismatch, pip can print information
> in both cases.  This would go a long way to alleviating the confusion that
> occurs when users back themselves into one of these corners, and would alert
> users to potential issues before they become a problem; right now you have
> to be a dogged investigative journalist to figure out why pip is doing the
> wrong thing in some cases.

I don't see how such checks would work on Windows. The "simple"
approach would involve invoking a subprocess to check what "python"
resolved to, which is a non-trivial overhead on Windows.

Could you explain how you'd do a check like this on Windows?
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 5 November 2015 at 22:59, Donald Stufft  wrote:
> I think we could integrate with py on Windows somehow so that we use the same 
> lookup semantics as py does. I don't know enough about Windows and py.exe to 
> know what exactly those are.

Hmm, I'm reluctant to get into complex interactions with C code like
the launcher on Windows. The number of people we'd have able to
maintain such code is approaching zero, I suspect :-( We may be able
to run py.exe as a subprocess, but that could easily get out of hand
(running pip could then easily start up a chain of 6 processes on
Windows, which while not disastrous, certainly isn't cheap).

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Michael Merickel]

On Fri, Nov 6, 2015 at 12:33 PM, Ionel Cristian Mărieș 
wrote:

> ​Why not consider having a "pip" launcher?​ Seems the obvious thing to me
> - python has the "py" launcher on windows and it works great!
>
> Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using
> python3.5 - just like the "py" launcher.
>

This sounds similar to node's approach to bundling npm where you have a
version of npm that runs for all projects using that node runtime. In
effect you use the same npm binary independent of which virtualenv you are
using, it's tied to the interpreter installation. So you run the pip that
came with that python, such as pip2.7 installed with python2.7 and then
just tell it which virtualenv to install packages into. You could go
further and install a pip alias into the virtualenv that links to the
appropriate pip, but there's still only one copy running for all
virtualenvs off of that interpreter.

This model is really nice for updating because you don't need to update pip
inside every single virtualenv. Another cool feature of npm is that it's
also effectively auto-using the virtualenv since it defaults to the local
node_modules folder so you don't have to specify it as something like "pip
--virtualenv=env install".

Anyway I'm not suggesting such a drastic change but it's nice to look at
what else is out there and the benefits. It doesn't mesh particularly well
verbatim with how PYTHONPATH+virtualenv works of course.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Nathaniel Smith]

On Nov 6, 2015 5:39 AM, "Paul Moore"  wrote:
>
> On 6 November 2015 at 12:10, Donald Stufft  wrote:
> > Doesn’t py.exe just look at some ini files and environment variables to
decide what to invoke? I’m not sure why we couldn’t just replicate that
behavior. Is there something that py.exe does that we can’t also do in
Python?
>
> What's there might be possible in Python, but there are some nasty
> special cases. The launcher code looks in the registry, and in order
> to support running both 32 and 64 bit Pythons from the same launcher
> exe, it needs to play tricks to see both the 32 and 64 bit registry
> values, and I'm not sure the APIs to do that are exposed to Python so
> it may need ctypes.
>
> Doable certainly, easy not so sure. We could of course do a simplified
> version and not try to be precisely equivalent to the launcher
> behaviour - but that may also cause user confusion. The simplest cases
> are easy, it's the corner cases that get nasty.

One option would be to add a "py -which" mode that just does the
configuration lookup and then prints the path to the real python
executable. This would add the cost of one subprocess startup per pip, but
not 6?

-n
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Tim Golden]

On 06/11/2015 14:46, Nathaniel Smith wrote:
> On Nov 6, 2015 5:39 AM, "Paul Moore"  > wrote:
>>
>> On 6 November 2015 at 12:10, Donald Stufft  > wrote:
>> > Doesn’t py.exe just look at some ini files and environment variables
> to decide what to invoke? I’m not sure why we couldn’t just replicate
> that behavior. Is there something that py.exe does that we can’t also do
> in Python?
>>
>> What's there might be possible in Python, but there are some nasty
>> special cases. The launcher code looks in the registry, and in order
>> to support running both 32 and 64 bit Pythons from the same launcher
>> exe, it needs to play tricks to see both the 32 and 64 bit registry
>> values, and I'm not sure the APIs to do that are exposed to Python so
>> it may need ctypes.
>>
>> Doable certainly, easy not so sure. We could of course do a simplified
>> version and not try to be precisely equivalent to the launcher
>> behaviour - but that may also cause user confusion. The simplest cases
>> are easy, it's the corner cases that get nasty.
> 
> One option would be to add a "py -which" mode that just does the
> configuration lookup and then prints the path to the real python
> executable. This would add the cost of one subprocess startup per pip,
> but not 6?

FWIW this will do that:

  py -c "import sys; print(sys.executable)"

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Marius Gedminas]

On Fri, Nov 06, 2015 at 02:04:38PM +1300, Robert Collins wrote:
> On 6 November 2015 at 10:08, Donald Stufft  wrote:
> > * It's more to type, 10 more characters on *nix and 6 more characters on
> >   Windows which makes it more akward and annoying to use. This is 
> > particularly
> >   annoying inside of a virtual environment where there isn't really any
> >   ambiguity when one is activated.
> 
> cat > /usr/bin/pip << EOF
> python -m pip $@
> EOF
> 
> Seriously - isn't the above entirely sufficient?

It doesn't help with my usual pattern, which used to be

  $ virtualenv .
  $ bin/pip install foo

but then changed[*] into

  $ virtualenv .venv && ln -sfn .venv/bin bin
  $ bin/pip install foo

and is likely to change[+] into

  $ virtualenv .venv && mkdir -p bin && ln -sfn .venv/bin/pip bin/pip
  $ bin/pip install foo

I am not running these by hand -- I have Makefiles to set up my app
environment by creating a local virtualenv and pip installing all the
tools, plus '-e .', into it.  But once the basic environment is done,
I'm often installing ad-hoc one-time-use extra tools with commands like

  $ bin/pip install runsnakerun

---

  [*] because virtualenv's root is becoming too cluttered with files like
  pip-selftest.json, and because some evil packages on PyPI install
  files named README.txt into the virtualenv root.

  [+] because if you symlink just the bin/ directory, bin/python fails to
  set up sys.path correctly

Marius Gedminas
-- 
I'm sure it would be possible to speed apport up a lot, after we're done
making boot and login instantaneous.
-- Lars Wirzenius


signature.asc
Description: Digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 6 November 2015 at 14:56, Tim Golden  wrote:
>> One option would be to add a "py -which" mode that just does the
>> configuration lookup and then prints the path to the real python
>> executable. This would add the cost of one subprocess startup per pip,
>> but not 6?
>
> FWIW this will do that:
>
>   py -c "import sys; print(sys.executable)"

Indeed. We don't want to require modifications to py.exe, as that
would imply some sort of "Python 3.6 only" requirement (there are
backport options, as the launcher is largely independent from Python
itself, but that's yet more obstacles for end users).

Don't take the 6 processes too literally, but just to explain:

pip launcher
- runs Python. Either directly (= 2 processes so far) or via
py (= 3 processes so far)
- checks what Python it's running (just code to read
sys.executable in pip)
- processes the -p flag
- runs py -c "import sys; print(sys.executable)" to work
out what version the -p flag is requesting
  (unless -p requires the full pathname of an executable,
which is lousy UI)
  That's 2 more processes run, albeit only for a short time
- Finds out it needs a different exe, launches py for the
correct Python (add 2 more processes to the stack, we're at 5 now).
- The subordinate pip runs sys.executable to execute
setup.py (1 more process) which in turn launches the C compiler
  (that's a stack of 7 processes)

It's quite likely that this can be trimmed, and normal cases won't be
nearly as bad. And while creating new processes on Windows is
distinctly worse than on Linux, it's not *that* bad.

But when wheels were introduced, installing via wheels rather than via
setup.py caused *substantial* time savings when installing pure Python
wheels, simply from removing process creation overheads (creating a
virtualenv, which installed setuptools and pip at the time, i.e., 2
wheels instead of 2 sdists, went from something like 30 seconds down
to a couple of seconds, if I recall).

I'm not wanting to make a big issue out of this, but it needs to be
considered...
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Wolfgang Maier]

On 11/05/2015 10:08 PM, Donald Stufft wrote:


* There is a lot of documentation out there in many projects that tell people
   to use ``pip install ...``, the long tail on getting people moved to this
   will be very long.



The deprecation period will probably have to be long, but the current 
situation is not so bad that you could not live with it for a bit longer.



* It's more to type, 10 more characters on *nix and 6 more characters on
   Windows which makes it more akward and annoying to use. This is particularly
   annoying inside of a virtual environment where there isn't really any
   ambiguity when one is activated.



I have no problem with the extra characters, just as I don't have a 
problem with typing: java -jar xy.jar


The extra typing might be annoying for the pypa devs, but remember that 
many regular users have to type this only once in a while when they 
install some new package. For them, its far more important that things 
work reliably than with the shortest possible command.




* It still has the annoyance around having multiple pip installs all over the
   place and needing to manage those.



Another experts problem. People who are just using "Python" and a few 
third-party packages are not suffering from this. Once they get to a 
level where they use multiple versions of python, they will be able to 
cope with the multiple pip installations.




* We still support Python 2.6 which doesn't support executing a package only
   modules via ``-m``. So we'll break Python 2.6 unless people do
   ``python -m pip.__main__`` or we move pip/* to _pip/* and make a pip.py which
   will break things for people using pip as a library (which isn't currently
   supported).



How much longer are you planning to support Python 2.6? Why not just 
deprecate pip and pipX.Y (emit a warning to users) for newer versions of 
Python. Then once you drop Python 2.6 support remove pip and pipX.Y.



python -m pip ... may not read that beautifully, but if lack of beauty 
is the last remaining problem to Python packaging, then that's a reason 
to celebrate, isn't it.


Best,
Wolfgang

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 6 November 2015 at 12:10, Donald Stufft  wrote:
> Doesn’t py.exe just look at some ini files and environment variables to 
> decide what to invoke? I’m not sure why we couldn’t just replicate that 
> behavior. Is there something that py.exe does that we can’t also do in Python?

What's there might be possible in Python, but there are some nasty
special cases. The launcher code looks in the registry, and in order
to support running both 32 and 64 bit Pythons from the same launcher
exe, it needs to play tricks to see both the 32 and 64 bit registry
values, and I'm not sure the APIs to do that are exposed to Python so
it may need ctypes.

Doable certainly, easy not so sure. We could of course do a simplified
version and not try to be precisely equivalent to the launcher
behaviour - but that may also cause user confusion. The simplest cases
are easy, it's the corner cases that get nasty.

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Thu, Nov 5, 2015 at 11:08 PM, Donald Stufft  wrote:

> Currently pip installs a number of commands like ``pip``, ``pipX`` and
> ``pipX.Y`` where the X and X.Y corresponds to the version of Python that
> pip
> is installed into. Pip installs into whatever Python is currently
> executing it
> so this gives some ability to control which version of Python you're
> installing
> into (``pip2.7`` for Python 2.7 etc).
>

​Why not consider having a "pip" launcher?​ Seems the obvious thing to me -
python has the "py" launcher on windows and it works great!

Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using
python3.5 - just like the "py" launcher.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

> On Nov 6, 2015, at 1:33 PM, Ionel Cristian Mărieș  wrote:
> 
> 
>> On Thu, Nov 5, 2015 at 11:08 PM, Donald Stufft  wrote:
>> Currently pip installs a number of commands like ``pip``, ``pipX`` and
>> ``pipX.Y`` where the X and X.Y corresponds to the version of Python that pip
>> is installed into. Pip installs into whatever Python is currently executing 
>> it
>> so this gives some ability to control which version of Python you're 
>> installing
>> into (``pip2.7`` for Python 2.7 etc).
> 
> ​Why not consider having a "pip" launcher?​ Seems the obvious thing to me - 
> python has the "py" launcher on windows and it works great!
> 
> Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using 
> python3.5 - just like the "py" 

Isn't this basically what the third option is?  Just the launcher is also the 
entire program. ___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Fri, Nov 6, 2015 at 11:13 PM, Donald Stufft  wrote:

> Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using
> python3.5 - just like the "py"
>
>
> Isn't this basically what the third option is?  Just the launcher is also
> the entire program.
>

​If you mean the initial mail you have send, I only saw two proposals:
`python -mpip` and something with zipfiles. Not sure if having a zipfile
around counts as a launcher, you wouldn't call something a launcher if it
contains the target completely no?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 6, 2015 at 4:59:39 PM, Ionel Cristian Mărieș (cont...@ionelmc.ro) 
wrote:
> On Fri, Nov 6, 2015 at 11:13 PM, Donald Stufft wrote:
>  
> > Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using
> > python3.5 - just like the "py"
> >
> >
> > Isn't this basically what the third option is? Just the launcher is also
> > the entire program.
> >
>  
> If you mean the initial mail you have send, I only saw two proposals:
> `python -mpip` and something with zipfiles. Not sure if having a zipfile
> around counts as a launcher, you wouldn't call something a launcher if it
> contains the target completely no?
>  

Well, it’s not really a launcher no, but you’d do ``pip -p python2 install 
foo`` or something like that. It’s the same UI. Having just a “launcher” I 
think is actually more confusing (and we already had that in the past with -E 
and removed it because it was confusing). Since you’ll have different versions 
of pip in different environments (Python or virtual) things break or act 
confusingly.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

> On Nov 5, 2015, at 5:41 PM, Paul Moore  wrote:
> 
>> On 5 November 2015 at 21:08, Donald Stufft  wrote:
>> Thoughts?
> 
> The executable zip solution is in principle the best long-term
> solution. But the breakage is major, and it pretty much permanently
> cuts off any option to support use of pip as a library. That's
> probably OK, but we need to understand that fact.
> 
> Further downsides to the executable zip approach:
> 
> 1. We still need an "exe wrapper" on Windows. This can be as simple as
> prepending a stub exe to the zip, but we'd need either to maintain
> such a stub ourselves or find a supplier of one.

I think we can still use the ones we use now, although they might not support a 
zip file. Afaik they just execute a python script and I guess (hope) that they 
don't validate that and a zip file can be a "script" too. 

> 2. The Python 3.5 zipapp module includes support for a .pyz extension
> that is registered as a "zipped Python application". But as you noted,
> .exe is treated specially in certain places in Windows, and so there
> really is no alternative to a "pip.exe" command if we want the
> invocation to remain "pip".
> 3. On Windows, there is no guaranteed location that is on PATH. If we
> supply a "pip.exe" how will we ensure it's on the user's PATH? At the
> moment we take advantage of the Python installer (and virtualenv
> activate scripts) including the Python Scripts directory on PATH. If
> pip were an independent executable, we'd need people to manage PATH
> themselves.

I'm my mind we wouldn't be throwing out wheels, we'd just build this zip 
instead. So our wheels would only contain this executable pip zip as a script 
(not console entry point) and pip would automatically wrap them with exe on 
Windows. 

> 4. Wouldn't the executable zip still be run with a specific Python,
> coded in the wrapper or shebang line? You say it'd install into
> "python" by default. But what about on Windows where the py launcher
> gets "the default Python" from its ini file, not from what's on PATH?
> And to use a different Python, you're potentially talking about "pip
> -p C:\Users\xxx\AppData\Local\Programs\Python\Python35\python.exe".
> Over my dead body :-)

I think we could integrate with py on Windows somehow so that we use the same 
lookup semantics as py does. I don't know enough about Windows and py.exe to 
know what exactly those are. 

> 
> If I misunderstood, and your proposal is "python pip.zip", then
> there's still a problem as the *actual* usage would be "python
> C:\Whatever\Path\To\pip.zip" - which is far from user friendly.
> 
> Overall I think that "python -m pip" is the best compromise. Users can
> write their own wrapper scripts, shell functions or aliases for common
> usage. But they probably won't in practice. So there is a lot of pain
> for users (not just command line use, every script that does
> subprocess.call(['pip', ...]) would need changing).
> 
> Sadly, there's no really good solution :-(

Yup :(

> 
> It seems to me that the main questions are:
> 
> 1. Do we want the canonical invocation to remain "pip" or are we
> willing to break that? [I'm ambivalent on this, personally, but it's a
> significant compatibility break]

I'm also somewhat ambivalent by only because I'm just going to add an alias to 
restore "pip". 

> 2. Do we mind if there's a different command needed to upgrade pip? [I
> don't, as long as pip supports *some* command to upgrade itself]

I'm not sure if we'd need a different command to upgrade pip. In my head pip is 
still installed as a Python package. It'll just have non standard build steps. 

> 3. Do we want to move away from a pip per Python installation? [For
> me, it'd be somewhat convenient, but nonessential, and I suspect some
> people would have Python installations or virtualenvs where they want
> to have a *different* pip than the default one - so this change might
> actually be a regression for them]

There wouldn't be anything preventing you from installing multiple versions of 
pip into an environment as we do today. It just wouldn't be mandatory. 

> 
> Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Paul Moore]

On 5 November 2015 at 21:08, Donald Stufft  wrote:
> Thoughts?

The executable zip solution is in principle the best long-term
solution. But the breakage is major, and it pretty much permanently
cuts off any option to support use of pip as a library. That's
probably OK, but we need to understand that fact.

Further downsides to the executable zip approach:

1. We still need an "exe wrapper" on Windows. This can be as simple as
prepending a stub exe to the zip, but we'd need either to maintain
such a stub ourselves or find a supplier of one.
2. The Python 3.5 zipapp module includes support for a .pyz extension
that is registered as a "zipped Python application". But as you noted,
.exe is treated specially in certain places in Windows, and so there
really is no alternative to a "pip.exe" command if we want the
invocation to remain "pip".
3. On Windows, there is no guaranteed location that is on PATH. If we
supply a "pip.exe" how will we ensure it's on the user's PATH? At the
moment we take advantage of the Python installer (and virtualenv
activate scripts) including the Python Scripts directory on PATH. If
pip were an independent executable, we'd need people to manage PATH
themselves.
4. Wouldn't the executable zip still be run with a specific Python,
coded in the wrapper or shebang line? You say it'd install into
"python" by default. But what about on Windows where the py launcher
gets "the default Python" from its ini file, not from what's on PATH?
And to use a different Python, you're potentially talking about "pip
-p C:\Users\xxx\AppData\Local\Programs\Python\Python35\python.exe".
Over my dead body :-)

If I misunderstood, and your proposal is "python pip.zip", then
there's still a problem as the *actual* usage would be "python
C:\Whatever\Path\To\pip.zip" - which is far from user friendly.

Overall I think that "python -m pip" is the best compromise. Users can
write their own wrapper scripts, shell functions or aliases for common
usage. But they probably won't in practice. So there is a lot of pain
for users (not just command line use, every script that does
subprocess.call(['pip', ...]) would need changing).

Sadly, there's no really good solution :-(

It seems to me that the main questions are:

1. Do we want the canonical invocation to remain "pip" or are we
willing to break that? [I'm ambivalent on this, personally, but it's a
significant compatibility break]
2. Do we mind if there's a different command needed to upgrade pip? [I
don't, as long as pip supports *some* command to upgrade itself]
3. Do we want to move away from a pip per Python installation? [For
me, it'd be somewhat convenient, but nonessential, and I suspect some
people would have Python installations or virtualenvs where they want
to have a *different* pip than the default one - so this change might
actually be a regression for them]

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] The future of invoking pip

[Donald Stufft]

There is currently a semi related set of problems that I'd really like to figure
out an answer too so we can begin to work on a migration path and close these
out. This is dealing with a fairly fundamental aspect of pip so I'm bringing it
up here to try and get wider discussion than the issue tracker or pypa-dev
list.

Currently pip installs a number of commands like ``pip``, ``pipX`` and
``pipX.Y`` where the X and X.Y corresponds to the version of Python that pip
is installed into. Pip installs into whatever Python is currently executing it
so this gives some ability to control which version of Python you're installing
into (``pip2.7`` for Python 2.7 etc).

However, this has a few problems:

* It really only works if you only have one version of Python installed for
  each X.Y series, as soon as you have multiple versions in one series
  (including alternative implementations besides CPython) you run into a
  problem of which Python 2.7 is pip2.7 for and how do you invoke it for the
  *other* Python 2.7's. Something like pip2.7.8 is really ugly, and still
  doesn't solve the problem when you have multiple 2.7.8 installs and
  pip-pypy2-4.0 is even uglier.

* The above gets *really* confusing when ``pipX`` or ``pip`` do not agree with
  what ``pythonX`` and ``python`` point to.

* Having pip need to be installed into each Python means you end up with a
  bunch of independent pip installations which all need to be independently
  updated. We've made this better by having recent pips warn you if you're not
  on the latest version, but it's not unusual for me personally to have 30+
  different installations of pip on my personal desktop. That isn't great.

* Having ``pip`` on Windows requires us to create a "script wrapper" which is
  just a shim .exe that just executes a python script. This is due to the fact
  that Windows special cases .exe in places. This causes problems because you
  can't actually do ``pip install --upgrade pip`` on Windows because you'll get
  an error trying to update the script wrapper, you need to do
  ``py -m pip install --upgrade pip`` so the .exe file isn't currently open.

One possible solution to the above problems is to try and move away from using
``pip``, ``pipX`` and ``pipX.Y`` and instead push people (and possibly
deprecate ``pip`` ) towards using ``python -m pip`` instead. This makes it
unambigious which python you're modifying and completely removes all of the
confusion around that. However this too has problems:

* There is a lot of documentation out there in many projects that tell people
  to use ``pip install ...``, the long tail on getting people moved to this
  will be very long.

* It's more to type, 10 more characters on *nix and 6 more characters on
  Windows which makes it more akward and annoying to use. This is particularly
  annoying inside of a virtual environment where there isn't really any
  ambiguity when one is activated.

* It still has the annoyance around having multiple pip installs all over the
  place and needing to manage those.

* We still support Python 2.6 which doesn't support executing a package only
  modules via ``-m``. So we'll break Python 2.6 unless people do
  ``python -m pip.__main__`` or we move pip/* to _pip/* and make a pip.py which
  will break things for people using pip as a library (which isn't currently
  supported).

Another possible option is to modify pip so that instead of installing into
site-packages we instead create an "executable zip file" which is a simple zip
file that has all of pip inside of it and a top level __main__.py. Python can
directly execute this as if it were installed. We would no longer have any
command except for ``pip`` (which is really this executable zip file). This
script would default to installing into ``python``, and you can direct it to
install into a different python using a (new) flag of ``-p`` or ``--python``
where you can specify either a full path or a command that we'll search $PATH
for.

* We'll break the usage of ``python -m pip``.

* We'll break the usage of ``pipX`` and ``pipX.Y``.

* We'll break the usage of anyone using pip as a library (but this is not
  actually supported).

* We still can't do ``pip install --upgrade pip`` by default, and since there's
  no ability to do ``py -m pip install --upgrade pip`` we'll need to figure
  something out (perhaps skip updating the .exe? I don't know).

The first option is the status quo and thus doesn't represent any *new*
breakage but has all of the problems we have currently. The second option
uses the ``-m`` operater but has problems with 2.6 and it's not as nice to
type but it removes all the ambiguity. The third option introduces the most
breakage, but it removes all the amiguity *and* it removes the need to manage
a number of pip installations.

A side conversation here is that pip currently bundles a number of dependencies
inside of itself because it can't really have any dependencies. This works
fine but it's a bit of an annoyance 

Re: [Distutils] The future of invoking pip

[Barry Warsaw]

On Nov 05, 2015, at 04:08 PM, Donald Stufft wrote:

>One benefit of the third option is that we can remove the need to directly
>copy the bundled libraries into the pip source code and we can install just
>bundle it inside the built zip file.

This shouldn't be a problem from Debian's p.o.v. if we can adjust how packages
end up in the zip file.  If for example the zip contains wheels, and we finish
the dirtbike (or similiar) project to rewheel distro packages, we'd use those
pip-build-time generated wheels in the zip and be all good.  Of course, we'd
probably have to rebuild pip when we change any of those dependencies, but I
think that's tractable.

I think the proposed solution is a better user experience that either of
pipX.Y or `pythonX.Y -m pip`, so I'm glad you're experimenting with this
approach.

Cheers,
-Barry


pgpGEI2LPVpSf.pgp
Description: OpenPGP digital signature
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 5, 2015 at 5:06:07 PM, Barry Warsaw (ba...@python.org) wrote:
> On Nov 05, 2015, at 04:08 PM, Donald Stufft wrote:
>  
> >One benefit of the third option is that we can remove the need to directly
> >copy the bundled libraries into the pip source code and we can install just
> >bundle it inside the built zip file.
>  
> This shouldn't be a problem from Debian's p.o.v. if we can adjust how packages
> end up in the zip file. If for example the zip contains wheels, and we finish
> the dirtbike (or similiar) project to rewheel distro packages, we'd use those
> pip-build-time generated wheels in the zip and be all good. Of course, we'd
> probably have to rebuild pip when we change any of those dependencies, but I
> think that's tractable.

My current proof of concept “forces” it to use something pip installed (though 
it could be pip installing a dirtbike generated wheel) but it really only does 
that because the most expedient way to make it work was to ``pip install foo 
—target TMPDIR`` and then recursively copy that into the zip file. There’s a 
number of possible ways it could work though, and if we did it, we’d want to 
make sure that it worked in a way that was friendly to downstream too.

>  
> I think the proposed solution is a better user experience that either of
> pipX.Y or `pythonX.Y -m pip`, so I'm glad you're experimenting with this
> approach.

In a total vacuum I think so too, the biggest worry I have is that we aren’t in 
a vacuum and we’re going to be breaking (at some point at least, whenever the 
deprecation period ends) some major interfaces (pipX, pipX.Y) and (python -m 
pip) and some minor ones (importing pip).

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Robert Collins]

On 6 November 2015 at 10:08, Donald Stufft  wrote:
...
> One possible solution to the above problems is to try and move away from using
> ``pip``, ``pipX`` and ``pipX.Y`` and instead push people (and possibly
> deprecate ``pip`` ) towards using ``python -m pip`` instead. This makes it
> unambigious which python you're modifying and completely removes all of the
> confusion around that. However this too has problems:
>
> * There is a lot of documentation out there in many projects that tell people
>   to use ``pip install ...``, the long tail on getting people moved to this
>   will be very long.

I don't see that as a specific problem. It drags out the deprecation
period is all.

> * It's more to type, 10 more characters on *nix and 6 more characters on
>   Windows which makes it more akward and annoying to use. This is particularly
>   annoying inside of a virtual environment where there isn't really any
>   ambiguity when one is activated.

cat > /usr/bin/pip << EOF
python -m pip $@
EOF

Seriously - isn't the above entirely sufficient?

> * It still has the annoyance around having multiple pip installs all over the
>   place and needing to manage those.

This is a mixed thing. You *need* those installs when pip drops support for 2.6.

> * We still support Python 2.6 which doesn't support executing a package only
>   modules via ``-m``. So we'll break Python 2.6 unless people do
>   ``python -m pip.__main__`` or we move pip/* to _pip/* and make a pip.py 
> which
>   will break things for people using pip as a library (which isn't currently
>   supported).

Or the same wrapper approach can deal with this - as long as there is
a pip.__main__ on all Pythons.

> Another possible option is to modify pip so that instead of installing into
> site-packages we instead create an "executable zip file" which is a simple zip
> file that has all of pip inside of it and a top level __main__.py. Python can
> directly execute this as if it were installed. We would no longer have any
> command except for ``pip`` (which is really this executable zip file). This
> script would default to installing into ``python``, and you can direct it to
> install into a different python using a (new) flag of ``-p`` or ``--python``
> where you can specify either a full path or a command that we'll search $PATH
> for.

I don't like this because:
 - pip won't be able to be interrogated in the same way as all other
python packages can be
 - the breakage is huge :(.
 - it doesnt' actually solve the windows problem
 - it makes it hard to use pip except via a subprocess - and while its
not supported, it is at least in principle something we could be
working on (and there was interest in that on python-dev the other
month IIRC).

...
> A side conversation here is that pip currently bundles a number of 
> dependencies
> inside of itself because it can't really have any dependencies. This works
> fine but it's a bit of an annoyance to maintain. The larger problem is that a
> number of downstreams don't like this and have attempted to route around it to
> varying degrees of success. One benefit of the third option is that we can
> remove the need to directly copy the bundled libraries into the pip source 
> code
> and we can install just bundle it inside the built zip file.

Well, we could do that today - only bundle in get-pip.py, have
installed copies have dependencies.

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Donald Stufft]

On November 5, 2015 at 8:04:41 PM, Robert Collins (robe...@robertcollins.net) 
wrote:
> On 6 November 2015 at 10:08, Donald Stufft wrote:
> ...
> > One possible solution to the above problems is to try and move away from 
> > using
> > ``pip``, ``pipX`` and ``pipX.Y`` and instead push people (and possibly
> > deprecate ``pip`` ) towards using ``python -m pip`` instead. This makes 
> > it
> > unambigious which python you're modifying and completely removes all of the
> > confusion around that. However this too has problems:
> >
> > * There is a lot of documentation out there in many projects that tell 
> > people
> > to use ``pip install ...``, the long tail on getting people moved to this
> > will be very long.
>  
> I don't see that as a specific problem. It drags out the deprecation
> period is all.
>  
> > * It's more to type, 10 more characters on *nix and 6 more characters on
> > Windows which makes it more akward and annoying to use. This is particularly
> > annoying inside of a virtual environment where there isn't really any
> > ambiguity when one is activated.
>  
> cat > /usr/bin/pip << EOF
> python -m pip $@
> EOF
>  
> Seriously - isn't the above entirely sufficient?

It’s not particularly hard to do this (we could even make a pip-cli package on 
PyPI that did it). It’s just one more step and one more “weird” thing for 
newcomers. 

>  
> > * It still has the annoyance around having multiple pip installs all over 
> > the
> > place and needing to manage those.
>  
> This is a mixed thing. You *need* those installs when pip drops support for 
> 2.6.

Well, as I said to Paul, nothing in any of these proposals mandates that you 
must only have one installation. The only difference is the third thing makes 
it *possible* to only have one install (though since ``pip`` is the only name, 
it means it’s harder to install pip into 2.6 when it is altinstall’d into 
/usr/bin along with other Pythons since both the 2.6 supporting pip and the 
non-2.6 supporting pip will want to be called “pip”. It’s less of a big deal 
for virtual environments because they already have a separate bin directory. 
This would almost be akin to RHEL only supporting VM installations of their 
really old OSs.

>  
> > * We still support Python 2.6 which doesn't support executing a package only
> > modules via ``-m``. So we'll break Python 2.6 unless people do
> > ``python -m pip.__main__`` or we move pip/* to _pip/* and make a pip.py 
> > which
> > will break things for people using pip as a library (which isn't currently
> > supported).
>  
> Or the same wrapper approach can deal with this - as long as there is
> a pip.__main__ on all Pythons.

python -m pip is implemented via pip.__main__ so python -m pip.__main__ will 
function for as long as python -m pip does (unless Python drastically changes).

>  
> > Another possible option is to modify pip so that instead of installing into
> > site-packages we instead create an "executable zip file" which is a simple 
> > zip
> > file that has all of pip inside of it and a top level __main__.py. Python 
> > can
> > directly execute this as if it were installed. We would no longer have any
> > command except for ``pip`` (which is really this executable zip file). This
> > script would default to installing into ``python``, and you can direct it to
> > install into a different python using a (new) flag of ``-p`` or ``--python``
> > where you can specify either a full path or a command that we'll search 
> > $PATH
> > for.
>  
> I don't like this because:
> - pip won't be able to be interrogated in the same way as all other
> python packages can be

I’m not sure what you mean be “interrogated” but it doesn’t actually *prevent* 
it, it just makes it a bit harder. You’d be able to restore the current 
``import`` ability (assuming that’s what you meant by interrogated) by doing 
something like:

    $ PYTHONPATH=`which pip` python -c “import pip”

> - the breakage is huge :(.

This is my biggest problem with it :(

> - it doesnt' actually solve the windows problem

Yea, there’s no clean (and generic) solution to that besides python -m pip.

> - it makes it hard to use pip except via a subprocess - and while its
> not supported, it is at least in principle something we could be
> working on (and there was interest in that on python-dev the other
> month IIRC).

I’m almost entirely certain we’ll never really support using pip as anything 
but a subprocess. Having two APIs (a subprocess one, and a Python one) isn’t 
great and we’re always going to need a subprocess one for things like 
Chef/Puppet that isn’t written in Python. Even in that thread, I believe they 
decided to go with subprocess because of the problems of trying to run pip in 
process (things won’t show up as installed and such).

This is a bit of a mixed thing too though, because right now it’s trivially 
easy to use pip via import and so people do it when it’s not appropriate to do 
so (like inside of ``setup.py`` files), 

Re: [Distutils] The future of invoking pip

[Robert Collins]

On 6 November 2015 at 15:49, Glyph Lefkowitz  wrote:
>
> On Nov 5, 2015, at 5:04 PM, Robert Collins 
> wrote:
>
> cat > /usr/bin/pip << EOF
> python -m pip $@
> EOF
>
> Seriously - isn't the above entirely sufficient?
>
>
> Since I don't think anyone has pointed this out yet:
>
> No, it's not sufficient.  It doesn't work on Windows.

Why not? (Ignore the language I wrote my pseudocode in, an actual
thing would be a Python script that install would turn into a .exe)

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Glyph Lefkowitz]

> On Nov 5, 2015, at 6:36 PM, Donald Stufft  wrote:
> 
> I’m not really sure what the right answer is for something where the 
> particular version of Python you’re invoking it with (and that you’re 
> actually using Python) is important. python -m makes a lot of sense in that 
> area because it eliminates the need to have each tool create their own logic 
> for determining what python they are operating on but I think most people are 
> not going to be very familiar with the idea and I don’t know how well they’d 
> warm to it. The other option (that I can come up with) is baking that logic 
> into each tool (as pip and virtualenv do now) either via naming scheme or a 
> flag.

Rather than trying to figure out what the "right" way for users to invoke `pip´ 
to begin with is, why not just have Pip start providing more information about 
potential problems when you invoke it?

If you invoke 'pip[X.Y]' and it matches 'python -m pip' in your current 
virtualenv, don't say anything; similarly if you invoke 'python -m pip' and 
'which pip' matches.  But if there's a mismatch, pip can print information in 
both cases.  This would go a long way to alleviating the confusion that occurs 
when users back themselves into one of these corners, and would alert users to 
potential issues before they become a problem; right now you have to be a 
dogged investigative journalist to figure out why pip is doing the wrong thing 
in some cases.

-glyph

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Glyph Lefkowitz]

> On Nov 5, 2015, at 7:34 PM, Robert Collins  wrote:
> 
> Why not? (Ignore the language I wrote my pseudocode in, an actual
> thing would be a Python script that install would turn into a .exe)


It was not clear, in the example that you gave, that I was supposed to ignore 
the example that you gave ;).

-g___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig