On 22 January 2016 at 18:46, Nathaniel Smith <n...@pobox.com> wrote: >> I'd like to propose adding a special cased value to add to the installer >> file >> that will tell projects like pip that this particular installed thing is >> being >> managed by someone else, and we should keep our hands off of it. According >> to >> PEP 376 the supported values for this file are r"[a-z0-9_-.]", however I >> think >> since nobody has ever implemented it, we could expand that so that it so >> you >> can also have a special value, of "dpkg (system)" or maybe that's not >> worth it >> and we could just have "system" as a special value. > > I think we want more than just "system", because the same user could have > some packages managed by dpkg and some by conda, both of which have their > own dependency resolution mechanisms that are outside pip's and could get > broken if pip removes stuff willy-nilly. And when pip errors out, you want > to be able to explain to the user "this package is managed by conda, and > using pip on it may break your conda setup..." versus "this package is > managed by Debian, and using pip on it may break your Debian setup...".
Well, I would expect conda to be specifying "conda" in the INSTALLER file. That's what the file is intended for, surely? To record what tool installed the package? Equally, there seems to me to be no reason dpkg couldn't use "dpkg", and yum use "yum", etc. I just see Donald's suggestion of using "system" as a simple flag saying "the OS" in a generic way for distributions that don't (for some reason) *want* to name the specific installer in the INSTALLER file. Well, that and the fact that they could have done that for years now, so being able to say "just put "system" in there and be done with it please!" is a nice easy message to give to distributions. Honestly, this seems to me to be a bit of a non-discussion. My recollection of PEP 376 and the discussions around INSTALLER are that it was simply a place where install tools could say "hey, it was me that did this". It never got used largely because nobody seemed to care about having that information. Now pip is starting to care, but as far as I can see there are only 3 cases pip should care about: 1. The file says "pip". Do just as we do now, we control that package. 2. The file says something *other* than pip. We don't own the files, take appropriate action. Warn, require an extra flag, whatever - we can use what's in the file to say "files owned by FOO" but other than that there's no reason we should behave differently depending on what specific non-pip value we see. 3. There's no INSTALLER file. This is the awkward one, as we can't (yet) say that this means the file isn't owned by pip. In a few years maybe, but for now we have to assume it could be either of the above cases. So the message should be "if you want pip to be careful with your files, put something (probably your installer name, but in practice anything other than "pip") in INSTALLER". Longer term, other tools might taking the same approach as pip, at which point not using the same name as other tools becomes useful - at that point, a generic term like "system" could be a bad choice... Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
