> On 20/2/2019, at 20:38, Alex Walters <tritium-l...@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.
It is my understanding that the PEP already covers this: https://www.python.org/dev/peps/pep-0582/#security-considerations > While executing a Python script, it will not consider the __pypackages__ in > the current directory, instead if there is a __pypackages__ directory in the > same path of the script, that will be used. This is also mentioned in the Specification section: > In case of Python scripts, Python will try to find __pypackages__ in the same > directory as the script. If found (along with the current Python version > directory inside), then it will be used, otherwise Python will behave as it > does > currently. > 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? I am not in the position to comment on this in general, although I fully understand the concern as a volunteer myself. As one of the Pipenv maintainers, however, it is my personal opinion that this PEP would not be end up in the “yet another standard” situation, but even be beneficial to Pipenv, if done correctly. I hope this can provide some confidence :) > > 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-le...@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/ -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@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/M5M355RB3KL34VSTFTXH4ZUJYHMETVNK/
