On Fri, Oct 20, 2017 at 11:59 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Yeah, here's the gist of what I had in mind regarding the malware problem (i.e. aiming to ensure we don't get all of setup.py's problems back again):
- a package's own install hooks do *not* get called for that package
Doesn't that break the entry point caching use case that started this whole discussion? When you first install the caching package, then it has to immediately build the cache for the first time. I don't really have the time or interest to dig into this (I know there are legitimate use cases for entry points but I'm very wary of any feature where package A starts doing something different because package B was installed). But, I just wanted to throw out that I see at least two reasons we might want to "bake in" the caching as part of our PEPified metadata: - if we do want to add "install hooks", then we need some way for a package to declare it has an install hook and for pip-or-whoever to find it. The natural way would be to use an entry point, which means entry points are in some sense "more fundamental" than install hooks. - in general, the only thing that can update an entry-point cache is the package that's doing the install, at the time it runs. In particular, consider an environment with some packages installed in /usr, some in /usr/local, some in ~/.local/. Really you want one cache in each location, and then to have dpkg/rpm responsible for updating the /usr cache (this is something they're familiar with, it's isomorphic to stuff like /etc/ld.so.cache), 'sudo pip' responsible for updating the /usr/local cache, and 'pip --user' responsible for updating the ~/.local/ cache. If we go the install hook route instead, then when I do 'pip install --user entry_point_cacher' then there's no way that it'll ever have the permissions to write to /usr, and maybe not to /usr/local either depending on how you want to handle the interaction between 'sudo pip' and ~/.local/ install hooks, so it just... won't actually work as a caching tool. Similarly, it's probably easier to convince conda to regenerate a single standard entry point cache after installing a conda package, than it would be to convince them to run generic wheel install hooks when not even installing wheels. -n -- Nathaniel J. Smith -- https://vorpus.org