It probably requires some tests, but I need some help with it. I'm not really sure which test should I modify and how.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

• csdiff-pylint : FAILURE in 2m 33s

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

• csdiff-pylint : FAILURE in 2m 46s

I'm also not sure what to do with this:

copr/v3/proxies/project_chroot.py:51:4: R0914[too-many-locals]: ProjectChrootProxy.edit: Too many local variables (21/20)

copr/v3/proxies/project_chroot.py:51:4: R0914[too-many-locals]: ProjectChrootProxy.edit: Too many local variables (21/20)

Ignore this one.

Can you please add a longer description, including two examples (enabling and disabling module)?

Can you change this to --rpmbuild-with <value> --rpmbuild-with <value 2> ...? Also the description should claim that it is used like rpmbuild --with <value>.

It probably requires some tests, but I need some help with it.

There's one test-case broken by this PR, you could use that one as an example.
Perhaps that, when fixed, will be good enough? I would take a look at manual
testing of this feature next week.

And thank you very much for your contribution!

Can you change this to --rpmbuild-with <value> --rpmbuild-with <value 2> ...? Also the description should claim that it is used like rpmbuild --with <value>.

I took the description from webui (text field placeholder), perhaps it should be changed there as well?

It probably requires some tests, but I need some help with it.

There's one test-case broken by this PR, you could use that one as an example.
Perhaps that, when fixed, will be good enough? I would take a look at manual
testing of this feature next week.

How can I run the tests locally?

I took the description from webui (text field placeholder), perhaps it should be changed there as well?

In web-UI is something like:

You can specify rpmbuild --without options here for builds in the given chroot.
Space separated list of the rpmbuild without options

But enhancements there are OK as well :-)

How can I run the tests locally?

$ cd frontend && ./run_tests.sh

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

• csdiff-pylint : FAILURE in 3m 34s

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

• csdiff-pylint : FAILURE in 2m 23s

enabled or disabled

This raises TypeError: can only join an iterable when not specified. So I suppose the default=[] needs to be specified on the parser side.

--rpmbuild-with AAA --rpmbuild-with BBB sets just BBB

But I'm now more worried about how to properly send a "reset" action. This has never
been done before? @frostyx, ideas?

When edit-chroot is specified without those options, nothing changes. When
--rpmbuild-with OPT is specified, everything is re-set and OPT is in effect.
Now, when --rpmbuild-with OPT2 is specified, OPT is re-set.

enabled or disabled

Fixed

This raises TypeError: can only join an iterable when not specified. So I suppose the default=[] needs to be specified on the parser side.

Fixed

--rpmbuild-with AAA --rpmbuild-with BBB sets just BBB

Fixed, switched to action="append".

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

• csdiff-pylint : FAILURE in 2m 19s

With the current code, the following command just re-sets the "with options" field to an empty string:

$ copr edit-chroot praiskup/ping/fedora-rawhide-x86_64

It should be a no-op from the --rpmbuild-with/--rpmbuild-without perspective. Meh.

So, I think it is OK as it is, with the only exception: Omitting any of those three new options shouldn't reset the config.

Then there's a question how to actually clear the config when user wants to. Perhaps
we could have --no-rpmbuild-with?

This should be discussed, @frostyx, wdyt?

Of course, @schlupov too ^^, @frostyx is our notorious API contributor though.

I am not sure if it is a good idea to go with additional_modules naming because the field is used for both enabling but also disabling modules from the buildroot.

Then there's a question how to actually clear the config when user wants to. Perhaps
we could have --no-rpmbuild-with?

Possibly. Or we could add --reset <name>, --default <name>, --reset-to-default <name>, or something like this, that would take the field name. The advantage is that it could be easily used for any other option.

But I am a bit lost how is this a new situation different from editing project settings. I think we could inspire from apiv3_projects.py:edit_project function. In it, we distinguish between

• None - Ignore the field and leave it unchanged
• empty string - Reset the field value

So for resetting the value via CLI, one could do copr-cli ... --modules "".

None - Ignore the field and leave it unchanged

This should be (I believe it already is/was) applied here in this PR.

empty string - Reset the field value

This is a bit fuzzy IMO. Considering empty value can have its own semantics
than re-set for some fields (implemented in the future).

I kind of like the --reset idea, but mapping the argument to appropriate
field or command line option is not easy I guess (--reset rpmbuild-with ?).

I kind of like the --reset idea, but mapping the argument to appropriate
field or command line option is not easy I guess (--reset rpmbuild-with ?).

I think we should match the field names that get-chroot (or other) command returns, e.g.

$ copr-cli get-chroot @copr/copr/fedora-rawhide-x86_64
{
    "additional_packages": [],
    "additional_repos": [],
    "comps_name": null,
    "delete_after_days": null,
    "isolation": null,
    "mock_chroot": "fedora-rawhide-x86_64",
    "ownername": "@copr",
    "projectname": "copr",
    "with_opts": [],
    "without_opts": []
}

So e.g. --reset with_opts. It makes the most sense to me but we don't have to do it this way.

@pbrezina, thanks for your contribution. We agreed with @frostyx that we'll continue on top of this PR ... merging!

Great, thank you. Is there any ETA when this will be available in pypi?

Jakub is going to write the PR first, and then the release -- and it's not yet on the schedule. We do release cca each 2 to 3 months, last 14 old..
https://docs.pagure.org/copr.copr/release-notes/2021-11-11.html