Log file Viewer
#pypa logs for Saturday the 26th of May, 2018
[09:16:24] <Xel> Hi! I've got an issue with how to properly write a install_requires declaration: my package depended on pyldap (a fork of python-ldap, installing under the same 'ldap' namespace), which was now merged back to python-ldap. Is there a way to signal to pip that it should remove pyldap when installing python-ldap?
[11:03:59] <toad_polo> Presumably that would allow you to write packages that uninstall random other packages.
[11:04:36] <toad_polo> The pyldap people could release an empty package that depends on python-ldap, though.
[11:34:17] <Xel> toad_polo: yeah, provided the user upgrades my library and pyldap in the proper order, so that the 'empty' pyldap version is installed before the new python-ldap
[11:34:45] <Xel> toad_polo: I was thinking of the Obsoletes: keyword from https://www.python.org/dev/peps/pep-0314/#obsoletes-multiple-use ; is it supported by pip / setuptools? don't think so, but you never know ;)
[11:35:29] <Xel> toad_polo: basically, python-ldap 2.5 and pyldap-2.5 both install the ldap package. pyldap 3.0 installs nothing and depends on python-ldap>=3.0 (post-mergeback)
[11:35:36] <toad_polo> If the user upgrades either pyldap or your library it will be determined that a new version of python-ldap is necessary.
[11:36:50] <Xel> yeah, but if they start with pyldap-2.5, then install python-ldap 3.0, then install pyldap-3.0, they'll have conflicts when installing python-ldap (same files as pyldap), and they'll get removed when replacing pyldap-2.5 with the empty pyldap-3.0
[11:38:34] <toad_polo> I think the more plausible scenario that causes problems is that pyldap 2.5 exists on disk and they don't upgrade it.
[11:39:23] <Xel> yeah, because it would no longer be a dependency so pip would have no reason to upgrade it
[11:40:53] <toad_polo> Yeah, I'm not actually sure, I can dig in to the setuptools code a bit later to see if Obsoletes is supported.
[11:41:18] <Xel> I think it would be simpler to handle that in my library's code, or maybe in pyldap
[11:42:38] <toad_polo> Based on this, I'm thinking it doesn't look good: https://stackoverflow.com/questions/28064563/how-can-i-mark-a-package-as-obsolete-with-setup-py
[13:50:29] <toad_polo> Xel: Turns out you can pass `obsoletes` into `setuptools.setup` and it will add `Obsoletes` to the package metadata
[14:08:43] <ronny> toad_polo: i beleive thats a foeld of a old standard thats not actually taken into account by any tooling
[14:34:02] <toad_polo> ronny: Yes, it seems that there's an `Obsoletes-Dist`, but I'm not sure why it's different from `Obsoletes`
[17:50:50] <toad_polo> `Obsoletes` comes from `distutils`, it's in PEP 314: https://www.python.org/dev/peps/pep-0314/#obsoletes-multiple-use
[18:33:37] <toad_polo> dstufft: I dunno, that was my thought at first, too, but I'm not sure it's a *big* problem.
[18:34:08] <toad_polo> What happens if you just have a package that just provides a `django` package now?
[18:35:27] <toad_polo> And there's a pretty significant real use case for this, which is people who create drop-in replacements that are intended to displace other software, particularly forks where the original maintainers are unresponsive.
[18:36:21] <toad_polo> I am not sure it would be terrible if `ruamel.yaml` had been able to provide just a `yaml` package and declare that it obsoletes `pyyaml`.
[18:37:02] <toad_polo> I think right now the conflicting packages fail silently, whereas this would fail at install time if you had drop-in-replacement packages.
[18:38:10] <toad_polo> I do think either way it makes sense for it to be able to go the other way, where `pyyaml` can say, "Actually use `ruamel.yaml`", but that leads to the same problem that Xel was discussing above.
[18:38:51] <toad_polo> Namely that if all your dependencies explicitly depend on the obsoleting package, the obsoleted package will end up orphaned.
[22:23:13] <njs> toad_polo: 'Conflicts-Dist' metadata would definitely be useful to track packages that don't work together (possibly with particular versions) -- there are a number of cases where this happens, beyond forks
[22:23:38] <njs> unfortunately pip needs a resolver before a Conflicts-Dist field can do anything useful
[22:24:10] <njs> and I feel like it's unclear what semantics people expect from Obsoletes-Dist, beyond what Conflicts-Dist would do?
[23:38:19] <njs> AFAIK the non-Dist versions of these fields mostly come from Long Long Ago, when there was no pip or pypi or anything and the metadata spec was mostly based on guesses and good intentions
[23:38:50] <njs> and then the -Dist versions are from an era where people tried to clean up some of the stuff from the previous era, but didn't necessarily rethink it all from scratch
[23:44:02] <toad_polo> In any case, yeah, I think opening it up to Conflicts is probably useful in some general sense, but Obsoletes already exists and it has a pretty clear usage.
[23:44:18] <toad_polo> It's a bit weird that it's in the spec but the metadata isn't actually used anywhere by anything.
[23:45:04] <njs> it's clear when you might tag something as Obsoletes:, but it's not at all clear what tools should do in response to that tag :-)
[23:46:05] <njs> because it's not making a specific technical claim, it's making a kind of social organizational claim: "we think downstream users should consider switching to this other thing"
[23:53:25] <njs> (a priori, it would even make sense to use the Obsoletes: tag for two packages that can be installed at the same time, but where one is the old deprecated one and people should be switching to the other)