There is an IRC chat, but moving it here to get everyone's opinion and consensus. Snakeoil as a seperated library from pkgcore doesn't provide value.
The only direct consumer that doesn't also dep on pkgcore is https://github.com/pkgcore/pychroot , archived in '23, and not in gentoo. It has no value as a stand alone library, so there is no 'pro' beyond hypothetical, one that I think is limited. Current tree results for context:
(venv) ferringb@frith ~/gentoo $ pquery --revdep-pkg dev-python/snakeoil | cut -d\ -f1
WARNING pkgcore: EAPI '9' isn't fully supported
app-portage/nattka-0.4.2-r1
dev-util/pkgcheck-0.10.37-r1
dev-util/pkgcheck-0.10.39
dev-util/pkgdev-0.2.12
dev-util/pkgdev-0.2.14
sys-apps/pkgcore-0.12.30-r1
sys-apps/pkgcore-0.12.32
The con is managing the semver compatibility and seperated released cycles, which is historically a PITA. It's a bit easier w/ our GH harness, exempting that introduces it's own devex issues.
As to how to do this:
- bulk import snakeoil into pkgcore.snakeoil. Rewrite pkgcore internals to use that.
- Mark snakeoil library access, itself as deprecated. That's easier to do than it sounds.
- Any snakeoil changes go into both
- This continues until the downstream pkgcheck/pkgdev/naatka have released with the equivalent of
s/snakeoil/pkgcore.snakeoil/, and dropped the direct dep on snakeoil.
- freeze snakeoil project, and transfer across the issues that are worth preserving.
- wipe the snakeoil ebuild at some point in the future when there are no further revdeps remaining.
Having pkgcore.snakeoil as an API admittedly seems hackish. For a simple migration like above, it's the fastest/easiest way to do it. If you look at the pkgcore python namespace, there really isn't a good place to nest the sort of intrinsics that snakeoil carries- pkgcore.util is for pgkcore specific utils, not it's underlying tooling it uses.
Renaming it to something else makes sense, but I think this should be kept in it's own sub namespace rather than attempting to integrate it into everything else. Some of the snakeoil components will be moved out since they exist strictly for one thing in pkgcore, just to be clear, but that's not the majority.
Offhand, I realize this may seem like it's "shuffling code to shuffle code"- no gain. Reducing the semver and release crap is the gain. For pkgcheck and pkgdev, I've had to sed a couple API calls to use the modern name (iter_read_bash -> read_bash), but the bulk of "fix up the deprecation" has been within pkgcore itself, and the bulk of dancing I've been doing to avoid breaking semver has been exactly that- things pkgcore internally uses, but the downstreams don't.
@mgorny @arthurzam @thesamesam thoughts? CC whoever else may care, or if you're aware of another downstream user
There is an IRC chat, but moving it here to get everyone's opinion and consensus. Snakeoil as a seperated library from pkgcore doesn't provide value.
The only direct consumer that doesn't also dep on pkgcore is https://github.com/pkgcore/pychroot , archived in '23, and not in gentoo. It has no value as a stand alone library, so there is no 'pro' beyond hypothetical, one that I think is limited. Current tree results for context:
The con is managing the semver compatibility and seperated released cycles, which is historically a PITA. It's a bit easier w/ our GH harness, exempting that introduces it's own devex issues.
As to how to do this:
s/snakeoil/pkgcore.snakeoil/, and dropped the direct dep on snakeoil.Having
pkgcore.snakeoilas an API admittedly seems hackish. For a simple migration like above, it's the fastest/easiest way to do it. If you look at the pkgcore python namespace, there really isn't a good place to nest the sort of intrinsics that snakeoil carries-pkgcore.utilis for pgkcore specific utils, not it's underlying tooling it uses.Renaming it to something else makes sense, but I think this should be kept in it's own sub namespace rather than attempting to integrate it into everything else. Some of the snakeoil components will be moved out since they exist strictly for one thing in pkgcore, just to be clear, but that's not the majority.
Offhand, I realize this may seem like it's "shuffling code to shuffle code"- no gain. Reducing the semver and release crap is the gain. For pkgcheck and pkgdev, I've had to sed a couple API calls to use the modern name (iter_read_bash -> read_bash), but the bulk of "fix up the deprecation" has been within pkgcore itself, and the bulk of dancing I've been doing to avoid breaking semver has been exactly that- things pkgcore internally uses, but the downstreams don't.
@mgorny @arthurzam @thesamesam thoughts? CC whoever else may care, or if you're aware of another downstream user