On Wed, Feb 20, 2019 at 12:27 PM Chris Jerdonek <chris.jerdo...@gmail.com> wrote:
> On Wed, Feb 20, 2019 at 5:59 AM 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. >> > > To this point, is this the right time and place to be discussing this PEP? > I don’t mind any discussion happening myself, but I’m wondering more for me > — if I should be digging up the questions I had about it and ask them here, > or continue holding off. > Technically any PEP that isn't rejected, withdrawn, or deferred is open for discussion, else the PEP was submitted prematurely. But in actual practice you need to ask the PEP authors. -Brett > > —Chris > > > 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/5KDK4LGHYYGWSE3RWC6M2RF6TZV5OPZR/ >
-- 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/MDGCGZYAGMXRKASYYN2QJCIN5GGOIXWL/
