I'd caution against folks getting too worked up about PEP 582. I know it's been getting a lot of attention on social media recently, but, it's a draft that hasn't even been submitted for discussion yet. Most PEPs at this stage never end up going anywhere. And in general, when people start digging in on positions for and against something it always leads to worse decisions, and the earlier this happens the worse it gets.

It has some interesting ideas and also some real limitations. I think it's a good signal that there are folks interested in helping make the python dev workflow easier, including changing the interpreter if that turns out to be the right thing to do. That's really all it means so far.

I wonder if we should stick a header on the PEP draft saying something like this? There's a lot of scattershot responses happening and I think a lot of the people reacting are lacking context.

-n

On Wed, Feb 20, 2019, 04:40 Alex Walters <tritium-list@sdamon.com> wrote:

I have 2 main concerns about PEP 582 that might just be me misunderstanding
the pep.

My first concern is the use of CWD, and prepending ./_pypackages_ for
scripts. For example, if you were in a directory with a _pypackages_
subdirectory, and had installed the module "super.important.module". My
understanding is that any scripts you run will have "super.important.module"
available to it before the system site-packages directory. Say you also run
"/usr/bin/an_apt-ly_named_python_script" that uses "super.important.module"
(and there is no _pypackages_ subdirectory in /usr/bin). You would be
shadowing "super.important.module".

In this case, this adds no more version isolation than "pip install --user",
and adds to the confoundment factor for a new user. If this is a
misunderstanding of the pep (which it very well might be!), then ignore that
concern. If it's not a misunderstanding, I think that should be emphasized
in the docs, and perhaps the pep.

My second concern is a little more... political.

This pep does not attempt to cover all the use-cases of virtualenvs - which
is understandable. However, this also means that we have to teach new users
*both* right away in order to get them up and running, and teach them the
complexities of both, and when to use one over the other. Instead of making
it easier for the new user, this pep makes it harder. This also couldn't
have come at a worse time with the growing use of pipenv which provides a
fully third way of thinking about application dependencies (yes, pipenv uses
virtualenvs under the hood, but it is a functionally different theory of
operation from a user standpoint compared to traditional pip/virtualenv or
this pep).

Is it really a good idea to do this pep at this time?

In a vacuum, I like this pep. Aside from the (possible) issue of unexpected
shadowing, it's clean and straight forward. It's easy to teach. But it
doesn't exist in a vacuum, and we have to teach the methods it is intended
to simplify anyways, and it exists in competition with other solutions.

I am not a professional teacher; I don't run python training courses. I do,
however, volunteer quite a bit of time on the freenode channel. I get that
the audience there is self-selecting to those who want to donate their time,
and those who are having a problem (sometimes, those are the same people).
This is the kind of thing that generates a lot of confusion and frustration
to the new users I interact with there.
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-leave@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/SFMFKTQVKTONCYNN7UEKLFAQ2VRKXEHK/