generate dist-info for Python bindings #447
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* ensures that `libdnf5` and `libdnf5_cli` Python bindings include minimal distribution metadata (per https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata). This makes the presence of the binding and its version visible to standard Python tools like `pip`.
nitzmahone
force-pushed
the
python_binding_distinfo
branch
from
8ce551b to
4ffe2e2
Compare
nitzmahone
commented
Apr 12, 2023
| @@ -376,6 +376,7 @@ Python 3 bindings for the libdnf library. | |||
|
|
|||
| %files -n python3-libdnf5 | |||
| %{python3_sitearch}/libdnf5 | |||
| %{python3_sitearch}/libdnf5-*.dist-info | |||
There was a problem hiding this comment.
I suppose this could also use the global project major/minor/patch vars to avoid the wildcard- can update that to do so if desired.
|
Thanks for the contribution, much appreciated! |
m-blaha
approved these changes
Apr 13, 2023
evan-goode
pushed a commit
to evan-goode/dnf
that referenced
this pull request
Oct 3, 2023
This is the DNF 4 cousin to this patch [0] for DNF 5. Per [1], Python packages should include some minimal distribution metadata, e.g. to make the package appear in `pip list`. Perhaps the "proper way" to generate this dist-info metadata would be to write a pyproject.toml and use a conventional Python build system like Poetry to build `python3-dnf` rather than doing it with CMake, but this is a way to do it with minimal changes to the build process. [0] rpm-software-management/dnf5#447 [1] https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata,
evan-goode
pushed a commit
to evan-goode/dnf
that referenced
this pull request
Oct 3, 2023
This is the DNF 4 cousin to this patch [0] for DNF 5. Per [1], Python packages should include some minimal distribution metadata, e.g. to make the package appear in `pip list`. Perhaps the "proper way" to generate this dist-info metadata would be to write a pyproject.toml and use a conventional Python build system like Poetry to build `python3-dnf` rather than doing it with CMake, but this is a way to do it with minimal changes to the build process. Closes RhBug:2239323 [2] [0] rpm-software-management/dnf5#447 [1] https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata, [2] https://bugzilla.redhat.com/show_bug.cgi?id=2239323 = changelog = msg: Add metadata for `dnf` Python package type: bugfix resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2239323
evan-goode
pushed a commit
to evan-goode/dnf
that referenced
this pull request
Oct 6, 2023
This is the DNF 4 cousin to this patch [0] for DNF 5. Per [1], Python packages should include some minimal distribution metadata, e.g. to make the package appear in `pip list`. Perhaps the "proper way" to generate this dist-info metadata would be to write a pyproject.toml and use a conventional Python build system like Poetry to build `python3-dnf` rather than doing it with CMake, but this is a way to do it with minimal changes to the build process. Closes RhBug:2239323 [2] [0] rpm-software-management/dnf5#447 [1] https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata, [2] https://bugzilla.redhat.com/show_bug.cgi?id=2239323 = changelog = msg: Add metadata for `dnf` Python package type: bugfix resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2239323
jan-kolarik
pushed a commit
to rpm-software-management/dnf
that referenced
this pull request
Oct 9, 2023
This is the DNF 4 cousin to this patch [0] for DNF 5. Per [1], Python packages should include some minimal distribution metadata, e.g. to make the package appear in `pip list`. Perhaps the "proper way" to generate this dist-info metadata would be to write a pyproject.toml and use a conventional Python build system like Poetry to build `python3-dnf` rather than doing it with CMake, but this is a way to do it with minimal changes to the build process. Closes RhBug:2239323 [2] [0] rpm-software-management/dnf5#447 [1] https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata, [2] https://bugzilla.redhat.com/show_bug.cgi?id=2239323 = changelog = msg: Add metadata for `dnf` Python package type: bugfix resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2239323
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #446
libdnf5andlibdnf5_cliPython bindings include minimal distribution metadata (per https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata). This makes the presence of the binding and its version visible to standard Python tools likepip, and makes it easier for, eg, Ansible users to discover if the bindings are available to the current Python.Note that
python3-rpmandpython3-gpgare already doing something similar (just using the older and largely deprecatedegg-infometadata instead ofdist-info).After build/install with this change:
I've also reserved
libdnf5andlibdnf5_clion PyPI, just in case someone decides to try and include one of these in a requirements/freeze file- it would work properly with this change if the OS-packaged libs are present, but don't want to let a malicious party grab those projects and get people installing who-knows-what in the case where they're not installed. Regardless if they're ever used to publish working versions of these (would be nice, hint hint 😉), I'm happy to hand the keys to those PyPI packages over to a maintainer if desired.