[Distutils] Maintaining a curated set of Python packages

[Nick Coghlan]

On 17 December 2016 at 06:40, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

> On Dec 16, 2016, at 5:51 AM, Daniel Holth <dholth at gmail.com> wrote:
>
> 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.
>

I'll also note that VSCode's Python plugin will find virtual environments
that are located inside the project directory by default. That approach of
"the virtualenv is inside the project directory" is probably a decent
pattern to recommend as a default, since it aligns with the way a lot of
IDEs (including VSCode itself) already work. When you use that model,
rather than being something you have to think about explicitly, the "Python
virtual environment" just becomes an implementation detail of how the IDE
manages your application dependencies, with the added bonus that *if you
want to*, you can re-use that environment independently of both the
application *and* the IDE.

And while I personally prefer to keep the notion of "project" and
"environment" more explicitly separate (i.e. I have an M:N mapping between
a collection of virtualenvs centrally managed with vex and the various
projects in my devel, fedoradevel and rhdevel folders, hence [1]), I
believe that level of complexity in a local dev setup isn't really normal
even for experienced programmers, let alone folks that are still early in
the learning process.

Cheers,
Nick.

[1] https://github.com/DonJayamanne/pythonVSCode/issues/569

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20161217/38b45851/attachment-0001.html>