>=dev-python/setuptools-8.0 bundles a package called "packaging". We should consider unbundling this into a separate ebuild per QA policy.
I was waiting for upstream to default to trying to load the system version before falling back which current versions now do (newer than what is in the tree now).
The latest pkg_resources/__init__.py on the default tries to use the bundled copy first. It was changed briefly to use the system copy first, but was then changed back. See also: https://github.com/jaraco/setuptools/commit/170657b68f4b92e7e1bf82f5e19a831f5744af67#commitcomment-9109448
On further though, since setuptools is the only consumer thus far, maybe we should just leave it alone.
(In reply to Mike Gilbert from comment #2) > The latest pkg_resources/__init__.py on the default tries to use the bundled > copy first. It was changed briefly to use the system copy first, but was > then changed back. > > See also: > > https://github.com/jaraco/setuptools/commit/ > 170657b68f4b92e7e1bf82f5e19a831f5744af67#commitcomment-9109448 Ah, I haven't been following upstream that closely. (In reply to Mike Gilbert from comment #3) > On further though, since setuptools is the only consumer thus far, maybe we > should just leave it alone. Pretty much was my opinion for the short term when I first noticed it was bundled.
Somewhow the if you don't already have setuptools installed, the unbundled version of packaging will fail to install. See bug #558658.
(In reply to Guilherme Amadio from comment #5) > Somewhow the if you don't already have setuptools installed, the unbundled > version of packaging will fail to install. See bug #558658. grr. I will look into that.
It is impossible to unbundle dev-python/packaging as it is a buildtime dependency. We cannot resolve this circular. commit 9313f9b5faba3b6930096de281101f8b71360810 Author: Justin Lecher <jlec@gentoo.org> Date: Tue Aug 25 10:15:06 2015 +0200 dev-python/setuptools: Revered unbundling of dev-python/packaging setuptools without packaging requires packaging which requires setuptools No way around this circular dependency as it is buildtime Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=534026 Package-Manager: portage-2.2.20.1 Signed-off-by: Justin Lecher <jlec@gentoo.org> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9313f9b5faba3b6930096de281101f8b71360810
Can't we use IUSE="system-packaging" to solve the circular dep?
(In reply to Manuel Rüger from comment #8) > Can't we use IUSE="system-packaging" to solve the circular dep? Sounds like pointless complexity to me. It looks like packaging got added to the tree as a dependency of pip? Can we revert that as well? I see no point in having it as a system lib.
(In reply to Mike Gilbert from comment #9) > (In reply to Manuel Rüger from comment #8) > > Can't we use IUSE="system-packaging" to solve the circular dep? > > Sounds like pointless complexity to me. > > It looks like packaging got added to the tree as a dependency of pip? Can we > revert that as well? I see no point in having it as a system lib. Why? upstream explicitly enables pip to have all libs unbundled.
(In reply to Justin Lecher from comment #10) > Why? upstream explicitly enables pip to have all libs unbundled. It just seems silly to unbundle a library that is only used by one package.
(In reply to Mike Gilbert from comment #11) > (In reply to Justin Lecher from comment #10) > > Why? upstream explicitly enables pip to have all libs unbundled. > > It just seems silly to unbundle a library that is only used by one package. pip bundles around a douzen libraries including colorama, ipaddress and progress which are either used by the users directly of other projects. By unbundling those, we also unbundle packaging.
Alright.
