On Dec 16, 2016, at 5:51 AM, Daniel Holth
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.
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/ 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. -glyph