I don’t have a ton of concern with regard to pipenv. We already just jump through hoops to modify paths and such at runtime, this honestly sounds like a cleaner approach. Obviously we won’t actually get to clean up the code for a long time but you know...
My basic position is that we are just pointing at python libraries and code at the end of the day. The only real concern is scripts— where will they live, etc. When TP mentions it will benefit Pipenv, one way he likely means is that it gives us the option of standardizing on where to put environments. This has been a bit contentious and our current default is one that is divisive. It also eliminates a lot of complexity that arises from that choice, including how we handle hashing and case sensitivity to derive virtualenv names across platforms (this has bitten us more than once). One final thing this enables as far as I understand is a sort of npm-like option for ignoring resolution conflicts and simply performing a sort of nested installation of subdependencies inside a top level dependency’s __pypackages__ folder. So if you did install two packages with a conflict, they wouldn’t necessarily have to find a resolution. My only concerns with this PEP relate to bloat. I’d be interested in ways to reduce duplication across a system with many such folders. Dan Ryan // pipenv maintainer gh: @techalchemy > On Feb 20, 2019, at 10:19 AM, Steve Dower <steve.do...@python.org> wrote: > >> On 20Feb.2019 0533, Tzu-ping Chung wrote: >> 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 :) > > I'd love to hear more about how Pipenv would make use of it. So far it's > only really been designed with pip in mind (and their team in the > discussion), but we've explicitly left it _very_ tool independent. So if > you can describe how it would work with Pipenv, that would be helpful > for finding things that need changing. > > Also, the `pythonloc` package is an implementation of this that anyone > can try out today - https://pypi.org/project/pythonloc/ (the major > difference is that when implemented, you won't have to use "pythonloc" > and "piploc" to get the new behaviour). > > Cheers, > Steve > -- > 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/JBEBTV4DBFMQ6GUUJPREFKYTP5TUAKF4/ -- 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/S4F7EHVTN7BWGFIRAHVKHGAAERSEJRGA/
