DNF5 prototype #5857
DNF5 prototype #5857
Conversation
pkratoch
had a problem deploying
to
gh-cockpituous
GitHub Actions
Failure
|
Hello @pkratoch! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2024-09-24 13:11:25 UTC |
pkratoch
had a problem deploying
to
gh-cockpituous
GitHub Actions
Failure
|
This dnf5 PR is needed for the prototype to finish the installation: rpm-software-management/dnf5#1697 |
| class DNFConfigWrapper(object): | ||
| """This is a temporary wrapper of a DNF config object.""" | ||
|
|
||
| def __init__(self, config): | ||
| """Wrap the DNF config object.""" | ||
| self._config = config | ||
|
|
||
| def __getattr__(self, name): | ||
| """Get the attribute. | ||
|
|
||
| Called when an attribute lookup has not found | ||
| the attribute in the usual places. | ||
| """ | ||
| option = getattr(self._config, name)() | ||
| return option.get_value() | ||
|
|
||
| def __setattr__(self, name, value): | ||
| """Set the attribute. | ||
|
|
||
| Called when an attribute assignment is attempted. | ||
| """ | ||
| if name in ["_config"]: | ||
| return super().__setattr__(name, value) | ||
|
|
||
| option = getattr(self._config, name)() | ||
| option.set(value) |
There was a problem hiding this comment.
Regarding the DNFConfigWrapper, right now, it is quite ugly, since the option names are in the form get_<name>_option. I have two possible solutions:
-
Remove the wrapper and access the options directly. This would look like this:
config.get_cachedir_option().get_value() config.get_cachedir_option().set(DNF_CACHE_DIR) -
Keep the wrapper, but use simple
<name>form in anaconda and wrap it with"get_" + name + "_option"in theDNFConfigWrapper.
The second solution would mean more readable access to the options, but the disadvantage is that it relies on a specific naming scheme in libdnf5. This could become a problem if we needed something else from the config e.g. to load config from parser (ConfigMain::load_from_parser), but it's not needed now. I prefer the second solution, but I don't know why the DNFConfigWrapper is described as temporary and what was the plan for future.
There was a problem hiding this comment.
I think i prefer to remove the wrapper. Or if you keep the wrapper, create access getters and settings for all used attributes.
I am not fond of the 2nd option - where we assume the "get" + name + "_option" naming scheme
As this can break easily
Does it make sense?
There was a problem hiding this comment.
I changed the wrapper to contain all the necessary options as properties. It got quite long, so let me know if it's acceptable. Maybe it could be moved to a separate file? Alternatively, I will change it to remove the wrapper entirely.
There was a problem hiding this comment.
@pkratoch I like it how it is now. Thanks
KKoukiou
force-pushed
the
master-dnf5_prototype
branch
from
f14b803
to
83ae896
Compare
KKoukiou
had a problem deploying
to
gh-cockpituous
GitHub Actions
Failure
pkratoch
force-pushed
the
master-dnf5_prototype
branch
from
83ae896
to
ed6f3f2
Compare
pkratoch
had a problem deploying
to
gh-cockpituous
GitHub Actions
Failure
|
I also pushed 2 commits changing the mocking in unit tests. Sorry I didn't notice it sooner that the tests do not pass. I am not totally sure about the second one that adds the try block, though. It's ok to do it like that in the test, but I am not sure if we can rely on dnf always sending the quit or error callback. If dnf crashed and didn't send anything, anaconda would wait forever. But I don't think there is anything that can be done on anaconda side. Also, I put the commits on top of the branch, but I would like to eventually amend the relevant commits in history, so that the history is not so chaotic. Let me know if it's ok to do that. |
Sure feel free to amend. |
pkratoch
force-pushed
the
master-dnf5_prototype
branch
from
ed6f3f2
to
0365101
Compare
pkratoch
had a problem deploying
to
gh-cockpituous
GitHub Actions
Failure
pkratoch
force-pushed
the
master-dnf5_prototype
branch
from
0365101
to
34f137e
Compare
pkratoch
had a problem deploying
to
gh-cockpituous
GitHub Actions
Failure
Use DNF5 in the Anaconda system installer for the package installation.
…nd setters The option getters were renamed in dnf5 in commit: rpm-software-management/dnf5/commit/740fd279d283156b8e9c3525a16142f2fffda291 So, with the previous approach, the names would have to be changed to `get_<name>_option` format, which would be wrong when they are used as atributes.
The dnf5 methods `Repo::fetch_metadata` and `Repo::load` were both removed from API. See: rpm-software-management/dnf5/commit/cc2ae250c30bdbd8fadb99a4eb9d817b074dc6b2 rpm-software-management/dnf5/commit/b2ece236b62d121c4e2ddd91272804db17ee7d12 Instead use `RepoSack::load_repos` to load all repositories. This method must be called only once.
The method was removed by commit: 0ff5e44
The test is adjusted because the base.setup() was already called. This might need to change if the place of calling base.setup() changes.
The method was removed by commit: rpm-software-management/dnf5@bfb6f32
There was a change regarding creation of the `ValidationReport`. It's no longer created in `CheckPackagesSelectionTask._resolve_selection()` but in `DNFManager.resolve_selection()`. The change lookgs good and it was probably even necessary because of changes in dnf reports from the transaction resolving, but it prevents testing the report messages, because the report is now also mocked. Since it's not a critical problem, I am disabling the message checks for now. The changes that caused the issue: poncovka@faccc47#diff-08489d103d5780dd5279cb390820b5eeb83963642783cd82773cef081803b1b7L620-L641 poncovka@faccc47#diff-57dffd56427be4eca900ee75e0a130414fb51527d206b00116ef9501f0784127L96-L114
The comps objects are owned by the queries, so when a query is destroyed, so are the contained objects. There is a bug for dnf: rpm-software-management/dnf5#1530 This is a temporary workaround.
The ValidationReport is now created within the mocked DNFManager.resolve_selection, so it must be mocked as well. Also, there are no longer exceptions raised from the DNF transaction, instead, the problems are stored in a report, so there are no exceptions to mock.
The base is no longer being closed and the resetting of base is tested in test_module_payload_dnf5_manager.DNFManagerTestCase.test_reset_base.
These tests probably didn't work at the time they were marked as skipped, but are working now.
Type 'void *' is expected as return from `add_new_download` and as `user_data` and `used_cb_data` arguments, so it cannot be easily used in Python. This is a workaround that fixes a segmentation fault, but a better solution is still needed.
The transaction can fail even if it doesn't contain any transaction items with an error status.
The transaction callbacks take libdnf5::base::TransactionPackage, not libdnf5::transaction::Package.
It's not on the API, see issue: rpm-software-management/dnf5#1644
The transaction_stop is actually for RPMCALLBACK_TRANS_STOP from rpm, which is only the end of preparation phase. The after_complete is called by dnf after the whole transaction completes. Also, the queue cannot be closed at this point, because transaction errors are written there after the transaction completes and then TransactionProgress.quit is called, which closes the queue as well.
pkratoch
force-pushed
the
master-dnf5_prototype
branch
from
34f137e
to
fca17eb
Compare
pkratoch
had a problem deploying
to
gh-cockpituous
GitHub Actions
Failure
No description provided.