On Fri, Dec 16, 2016 at 3:40 PM Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Dec 16, 2016, at 5:51 AM, Daniel Holth <dholth@gmail.com> wrote:

I'm also a visual studio code fan. It is the first editor I've tried that feels lightweight like Vim but has the power of many plugins. That, and the text rendering is excellent.

https://pypi.python.org/pypi/Stallion is a lovely GUI package manager.

There's a lot to like here - no disrespect to the Stallion team - but it's worth remembering this lesson from Havoc Pennington: https://blog.ometer.com/2016/01/26/the-dangerous-ui-team/

The major reason UI is important for this use-case - onboarding of new people to Python programming - is to give them discoverability on terms they're already familiar with.  That means that the first "UI" element has to be a cross-platform UI bundle.  Stallion is still a thing you have to install (and from what I can see, a thing you have to install into a virtualenv?)

One possibility to consider is that virtualenv itself is a bad idea. Why should the Python interpreter executable, rather than the program being run, determine the set of packages that is available for import? It is confusing and inconvenient to have to deal with environments at all. Yes, even if you are using a helper. Maybe there can be a better way to manage dependencies that is not completely disjoint from setup.py.

I can see why you'd say that, but I disagree.  I think the name "virtualenv" is really confusing, but the general idea of "it's the interpreter and not the app" is a very powerful concept because you can run a REPL (or a notebook, or a debugger, or a doc generator, or any other dev tool) in the same context as your application code, without actually loading or executing any specific thing from your application code.  Virtualenv also lets you easily control which Python version or interpreter (hello, pypy!) is being used in each context.

My point is really that virtualenv both causes and solves problems. There's jaraco's thing I was trying to remember https://pypi.org/project/rwt/ which is a creative alternative to virtualenv for some situations. I wish there was a smoother path between virtualenv develop-against-pypi-libraries and end-user application deployment.

Stallion has always looked cool but it hasn't been updated in a few years, I admit I never used it "for real". Don't know what it would it take to make a useful GUI package manager. Interactive dependency conflict resolution graphs? Able to install into remote environments? Maybe the command line version will always be easier to use.