I like the pep at first glance. I have long thought that virtualenv was a weird solution to an artificial problem notwithstanding that all programming problems are artificial. Virtualenv looks good only because a global interpreter centric environment is bad. A program centric alternative is welcome.
On Wed, Feb 20, 2019, 08:57 Nathaniel Smith <n...@pobox.com wrote: > 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-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. >> >> 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-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/5AGJJPMSWI7VIXXOBBYBH7PYINQI7HWM/ >
-- 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/T33UIQLXGDZJ2K6KAPGHLSIIILBYQFHF/
