On Wed, Feb 20, 2019, 08:13 Dan Ryan <dan@danryan.co> wrote:
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.
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.
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.
I don't think __pypackages__ would change anything here. The blocker for doing npm-style nested subdependencies in Python isn't that we only have one folder, it's that we only have one sys.modules, and I don't think there are any proposals to change that. -n