On Wed, Feb 20, 2019 at 8:49 AM Steve Dower
On 20Feb2019 0831, Nathaniel Smith wrote:
Yeah, __pypackages__ has no way to handle scripts, and also no way to access packages when you're running from a directory. Pipenv already handles both of these cases fine today, so I'm not sure how having __pypackages__ several years from now could help you.
Uh, it totally has both. It has no way to handle updating your terminal's environment for you, but it can put scripts *somewhere* ;)
It can also handle accessing packages when running from your project directory. If you meant subdirectory, sure, that would be a major security issue to do that (much as I want to), but if you meant "both scripts and -m don't work" then that's just incorrect.
Ugh, yeah, editing fail, I meant "subdirectory". And yeah, of course you can make both of these work, but I was specifically replying to Dan's comment about how he doesn't like pipenv has to jump through hoops and mess with paths manually. Maybe a better way to put it would be: the interpreter changes proposed in PEP 582 don't help pipenv, because even if pipenv ends up using __pypackages__ then the way it does it will be by jumping through hoops and messing with paths manually. The part that might benefit pipenv is to have a conventional place to put its environments. But that part doesn't need interpreter changes or even a PEP.
That said, I prefer the approach of pipx (https://pypi.org/project/pipx/) for scripts anyway. It too has the problem of not updating your PATH for you, but at least it keeps tools separate from dependencies, as they should be.
I think this is the third time we've had this conversation in a week :-(. Pipx is great for the cases it targets, and if it's sufficient for all of your use cases then that's great, but it isn't sufficient for mine, and that's not because your use cases are right and mine are wrong. (For anyone reading this and wondering about context, see: https://discuss.python.org/t/structured-exchangeable-lock-file-format-requir...) -n -- Nathaniel J. Smith -- https://vorpus.org