On Wed, Feb 20, 2019, 08:13 Dan Ryan <d...@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
-- 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/TFJ6M6Y3BC7SYW6D4XHAYVKFC3OIDR6X/
