python-daemon

#73 setuptools.extern.* is an implementation detail and breaks the build on Gentoo
Closed: Fixed by bignose. Opened by mgorny.

Closed: Fixed
Reopen Issue

The python-daemon package started using setuptools.extern.*. This "package" is an implementation detail of setuptools (not a public API) and it is not available on Gentoo where it is being stripped as part of unvendoring dependencies from setuptools:

gpep517 build-wheel --backend setuptools.build_meta --output-fd 3 --wheel-dir /tmp/portage/dev-python/python-daemon-3.0.0/work/python-d
aemon-3.0.0-pypy3/wheel
2023-03-04 05:16:43,757 gpep517 INFO Building wheel via backend setuptools.build_meta
Traceback (most recent call last):
  File "/usr/lib/python-exec/pypy3/gpep517", line 4, in <module>
    sys.exit(main())
  File "/usr/lib/pypy3.9/site-packages/gpep517/__main__.py", line 406, in main
    return func(args)
  File "/usr/lib/pypy3.9/site-packages/gpep517/__main__.py", line 202, in build_wheel
    print(build_wheel_impl(args, args.wheel_dir), file=out)
  File "/usr/lib/pypy3.9/site-packages/gpep517/__main__.py", line 194, in build_wheel_impl
    wheel_name = backend.build_wheel(str(wheel_dir), args.config_json)
  File "/usr/lib/pypy3.9/site-packages/setuptools/build_meta.py", line 413, in build_wheel
    return self._build_with_temp_dir(['bdist_wheel'], '.whl',
  File "/usr/lib/pypy3.9/site-packages/setuptools/build_meta.py", line 398, in _build_with_temp_dir
    self.run_setup()
  File "/usr/lib/pypy3.9/site-packages/setuptools/build_meta.py", line 335, in run_setup
    exec(code, locals())
  File "<string>", line 20, in <module>
  File "/tmp/portage/dev-python/python-daemon-3.0.0/work/python-daemon-3.0.0/version.py", line 39, in <module>
    import setuptools.extern.packaging.version
ModuleNotFoundError: No module named 'setuptools.extern'

Metadata Update from @bignose:
- Issue assigned to bignose
- Issue tagged with: confirmed, wishlist

Howdy @mgorny,

This "package" is an implementation detail of setuptools (not a public API)

That's true. On the other hand, the only use of that interface is in the context of assembling the package metadata, sometimes before any third-party packages have been installed.

And that's what 'python-daemon' is using that module for: assembling the package metadata (version information) during the build process.

not available on Gentoo where it is being stripped as part of unvendoring dependencies from setuptools

This, IMO, describes a bug in Gentoo, then. The Setuptools package deliberately bundles those external packages, precisely so that Setuptools can do packaging work before third-party packages have been fetched.

In light of that, I am marking this a "wishlist" item. I'd recommend convincing Gentoo to leave that part of Setuptools as-is.
Edited by bignose

I'm the Gentoo developer who actually removed these parts because they were breaking unvendoring. We have a clean setuptools bootstrap process, and python-daemon is in no way related to bootstrapping setuptools.

Would you accept a PR adding a fallback to regular packaging install on ImportError? Or is there some other solution you'd prefer?

Would you accept a PR adding a fallback to regular packaging install on ImportError?

I think it's reasonable to migrate to unconditional use of the ‘packaging’ package directly.

Here is a merge request to make that change, can you try it? Does it resolve this issue for you?

The changes in merge request 78 are now merged to the 'main' branch, as of commit d7bac6ed. Thanks to @mgorny for testing and confirming this resolves the issue.
Edited by bignose

Metadata Update from @bignose:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

I have now released ‘python-daemon’ version “3.0.2”, including the fix for this bug report.
Edited by bignose

Thank you!
Metadata

confirmed wishlist

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.