Proposal: Implement libdnf5 API in Python for Future Commands and Phase Out dnf commands
FelipeRuizGarcia opened this issue · 9 comments
Implement libdnf5 API
This PR intends to discuss the next steps regarding the integration of the libdnf5 API in Python to replace the current use of dnf commands. Additionally, it proposes phasing out the dnf5 plugin to accommodate the expansion to more commands beyond package management, as nvidia-open etc.
Open GPU kernel modules versus Proprietary drivers
https://github.com/NVIDIA/open-gpu-kernel-modules
Motivation:
Flexibility: The libdnf5 API offers a more flexible and programmable approach, allowing us to add new features and commands without relying on external command-line tools.
Future Expansion: Moving away from dnf5 plugins will open the door for broader functionality beyond the scope of traditional dnf operations.
https://dnf5.readthedocs.io/en/latest/api/index.html
https://github.com/rpm-software-management/dnf5/tree/main
Implement libdnf5 API:
Transition from using dnf at the command level to utilizing the libdnf5 API in Python.
This change is aimed at making the tool more adaptable for future developments and expanding beyond package management.
Next Steps:
Begin the integration process by replacing existing dnf command calls with corresponding libdnf5 API calls.
Gradually phase out the dnf5 plugin while ensuring backward compatibility during the transition period.
Document the new API usage and update any related documentation or scripts.
With the flexibility of the API, adding more features to configure repositories and packages becomes straightforward. For example, enabling Fedora Rawhide repositories.
What do you think ? please provide feedback.
@gridhead @onuralpszr
@FelipeRuizGarcia Apologies for the delayed reply - Let's do it.
Resources
- https://dnf5.readthedocs.io/en/latest/api/index.html
- https://dnf5.readthedocs.io/en/latest/api/python/python.html
- https://rpmfusion.org/Howto/NVIDIA
- Gotta retain executable permission for the binary after the builds are compressed
- Gotta have 100% test coverage of the functional codebase
On closer inspection - I'd like to wait until Fedora Linux 42 when DNF5 will become the norm. Jumping the gun could result disastrously on users as the dnf5 will have an overriding effect on the default dnf whenever the installation of this package leads to the installation of the libdnf dependency.
@FelipeRuizGarcia DNF5 seems to be the default in F41. Giving it a try now.
It still seems to be a bit early.
Installing python3-dnf5 would require me to override the dnf5 installed on system packages with the one I acquired from the COPR namespace of RPM Software Management. I would strongly discourage doing this and would much rather wait for one more release before this is normally available in the official Fedora Linux repositories.
It still seems to be a bit early.
Installing
python3-dnf5would require me to override thednf5installed on system packages with the one I acquired from the COPR namespace of RPM Software Management. I would strongly discourage doing this and would much rather wait for one more release before this is normally available in the official Fedora Linux repositories.
We don't need to wait for this, have distrobox we have toolbox we have devcontainer to work with it. It should be fairly easy to start develop without change your system dnf5 package etc.
@onuralpszr It will still require the same to be installed on their systems too. Messing with their package managers is something I do not encourage.
In my opinion, I have been using dnf5 for several months with Fedora Rawhide, and I find it quite stable. We could consider starting to develop stable libraries or beta versions of dnf5 and its derivatives.
To prevent issues with dnf5, we can use a virtual machine or containers. Personally, I use the nightly binaries of dnf5, and they work well. For development purposes, we could create a new branch to ensure no-riak and assume that, in the future, dnf5 and its derivatives will be stable. Additionally, as we develop and release the first beta of the auto installer using dnf5, we can conduct tests with the 'migration'.