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

[Stephen J. Turnbull]

Andrew Barnert writes:

 > Tcl/Tk, and Tkinter for all pre-installed Pythons but 2.3, have
 > been included with every OS X since they started pre-installing
 > 2.5.

My mistake, it's only MacPorts where I don't have it.  I used
MacPorts' all-lowercase spelling, which doesn't work in the system
Python.  (The capitalized spelling doesn't work in MacPorts.)

 > And it works with all python.org installs for 10.6 or later, all
 > Homebrew default installs, standard source builds... Just about
 > anything besides MacPorts (which seems to want to build Tkinter
 > against its own Tcl/Tk instead of Apple's)

I recall having problems with trying to build and run against the
system Tcl/Tk in both source and MacPorts, but that was a *long* time
ago (2.6-ish).  Trying it now, on my Mac OS X Yosemite system python
2.7.10, "root=Tkinter.Tk()" creates and displays a window, but doesn't
pop it up.  In fact, "root.tkraise()" doesn't, either.  Oops.  On this
system, IDLE has the same problem with its initial window, and
furthermore complains that Tcl/Tk 8.5.9 is unstable.

Quite possibly this window-raising issue is Just Me.  But based on my
own experience, it is not at all obvious that ensuring availability of
a GUI is possible in the same way we can ensure pip.

 > Also, why do you think Qt would be less of a problem?

I don't.  I think "ensure PyQt" would be a huge burden, much greater
than Tkinter.  Bottom line: IMO, at this point in time, if it has to
Just Work, it has to Work Without GUI.  (Modulo the possibility that
we can use an HTML server and borrow the display engine from the
platform web browser.  I think I already mentioned that, and I think
it's really the way to go.  People who *don't* have a web browser
probably can handle "python -m pip ..." without StackOverflow.)