[Python-ideas] High time for a builtin function to manage packages (simply)?

Stephen J. Turnbull stephen at xemacs.org
Mon Sep 7 03:51:23 CEST 2015


Terry Reedy writes:
 > On 9/5/2015 3:08 AM, Stephen J. Turnbull wrote:
 > 
 > > So let's fix it, already![1]  Now that we have a blessed package
 > > management module, why not have a builtin that handles the simple
 > > cases?  Say
 > >
 > >      def installer(package, command='install'):
 > >          ...
 > 
 > Because new builtins have a high threashold to reach, and this doesn't 
 > reach it?

In your opinion.  

And in mine!  Personally, I don't have a problem with remembering
python -m pip, nor do I have a problem with explaining it as
frequently as necessary to my students But there are only 20 of them,
rather than the thousands that folks like Steven (and you?) are
dealing with on python-list -- and there's the rub.

I'm suggesting this because of the vehemence with which Steven (among
others) objects to any suggestion that packages belong on PyPI, and
the fact that he can back that up with fairly distressing anecdotes
about the number of beginner posts asking about pip problems.  I would
really like to see that put to rest.

 > Installation is a specialized and rare operation.

help(), quit(), and quit are builtins.  I never use quit or quit()
(Ctrl-D works on all the systems I use), so I guess they are
"specialized and rare" in some sense, and I'm far more likely to use
dir() and a pydoc HTML server than help().

More to the point, the trouble packaging causes beginners and Steven
d'Aprano on python-list is apparently widespread and daily.  At some
point beginner-friendliness has enough value to make it into the
stdlib and even builtins.

 > Because pip must be installed anyway, so a function should be in the 
 > package and imported?
 >    from pip import main

I don't pronounce that "install".  Discoverability matters a lot for
the users in question (which is why I'm not happy with "installer",
but it's somewhat more memorable than "pip").

 > I think a gui frontend is an even better idea.

I think it's a great idea in itself.

But IMO it doesn't address this issue because the almost but not
really universally-available GUI is Tcl/Tk, which isn't even available
in any of the four packaged Python instances I have installed (Mac OS
X system Python 2.6 and 2.7, MacPorts Python 2.7 and 3.4, although
IIRC MacPorts offers a tk variant you can enable, but it's off by
default).

 > The tracker has a proposal to make such, once written, available
 > from Idle.
 >    https://bugs.python.org/issue23551
 > I was thinking that the gui code should be in pip itself

Obviously; it doesn't address the present issue if it's not ensured by
ensure_pip.  Which further suggests something like ensure_pyqt as
well.  (Or ensure_tk, if you think that perpetuating Tcl/Tk is
acceptable.)  I think that's a huge mess, given the size and messiness
of the dependencies.  I suppose a browser-based interface like that of
pydoc could deal with the "universality" issue, but I don't know how
fragile it is.



More information about the Python-ideas mailing list