On Fri, Dec 16, 2016 at 3:40 PM Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
> On Dec 16, 2016, at 5:51 AM, Daniel Holth <dho...@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.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
