The above means, that applications interfacing with Copr need to be aware of
these rules (are these documented somewhere?) and cannot work with groups
the same way as they work with "regular" namespaces.

If applications need to interface with copr they should use API. I suppose
the major problem you face is that you don't have all the needed API calls.
Can you please specify what is missing (of course even patches are welcome!).

It means that all API calls need to be compatible with @group syntax.

Non-API things are hard to document anywhere - please use the source.

If applications need to interface with copr they should use API.

Fair enough :)

I've tried to get the following information using a copr.v3.Client from the Python interface (python3-copr-1.101-1.fc31):

• web URL for a build (for example https://copr.fedorainfracloud.org/coprs/g/oamg/convert2rhel/build/1329535/) based on build_id - this would be needed b/c we (Packit) trigger builds in Fedora's Copr and we want to point our users to these builds.
• repo file URL for a chroot, based on owner and project names, for example: https://copr.fedorainfracloud.org/coprs/@oamg/convert2rhel/repo/epel-6/convert2rhel-epel-6.repo
• repo id that is used in repo files, based on owner and project names, for example copr:copr.fedorainfracloud.org:group_oamg:convert2rhel

The later two would be handy in Testing Farm, when installing packages to be tested. Currently there is some custom code for this.

Does the Python interface provide the information above? Did I miss something?

Thank you!

If applications need to interface with copr they should use API.

Fair enough :)
I've tried to get the following information using a copr.v3.Client from the Python interface (python3-copr-1.101-1.fc31):

web URL for a build (for example https://copr.fedorainfracloud.org/coprs/g/oamg/convert2rhel/build/1329535/) based on build_id - this would be needed b/c we (Packit) trigger builds in Fedora's Copr and we want to point our users to these builds.

This isn't yet in API (afaik, others can correct me), and indeed should
be. Something like copr build-info could expose that API from
commandline:

$ copr build-info
status: succeeded | ....
frontend_url: https://copr.fedorainfracloud.org/coprs/build/1330673/

Btw., the link I mention is owner agnostic - it is redireted to proper
owner (group or user).

repo file URL for a chroot, based on owner and project names, for
example:
https://copr.fedorainfracloud.org/coprs/@oamg/convert2rhel/repo/epel-6/convert2rhel-epel-6.repo

The same as we provide copr mock-config we should have copr repo
here. I missed this feature several times as well.

Note that those are aliases:
https://copr.fedorainfracloud.org/coprs/g/oamg/convert2rhel/repo/epel-6/convert2rhel-epel-6.repo
https://copr.fedorainfracloud.org/coprs/@oamg/convert2rhel/repo/epel-6/convert2rhel-epel-6.repo

repo id that is used in repo files, based on owner and project names,
for example copr:copr.fedorainfracloud.org:group_oamg:convert2rhel

This is hard one. As new features come, we change the format of the file
- and this only confirms that it is (probably) needed. But I don't know
your concrete use-case.

Note there can be two repo-IDs nowadays (if your project is
multilib),
and in future the file could hhave many other repositories (once we allow
runtime dependencies, see #1265).

That said, it is complicated - and currently only dnf-plugins-core handles
this well (it knows copr internals enough).

The later two would be handy in Testing Farm, when installing packages
to be tested. Currently there is some custom code for this. Does the
Python interface provide the information above? Did I miss something?

Perhaps you want to use this:

dnf -y copr enable  <OWNER/PROJECT>
dnf -y copr disable <OWNER/PROJECT>
dnf -y copr remove  <OWNER/PROJECT>

Btw., the link I mention is owner agnostic - it is redireted to proper
owner (group or user).

This is nice, and enables us to remove some code. Thanks!

This is hard one. As new features come, we change the format of the file
- and this only confirms that it is (probably) needed. But I don't know
your concrete use-case.

Testing Farm installs all packages from a given Copr repo, but needs to do this without knowledge what those packages are. So it will call dnf repoquery with --disablerepo=* --enablerepo=<repo-id> to find out and then install these packages. This is where the <repo-id> becomes handy.

You've already mentioned a possible copr repo command to get the repo file. How about an --id option for that to print only the repo-id? (And something equivalent on the API side.)

What should happen to this issue? Would it be better from a tracking pov if I opened separate issues for the 2/3 things above?

I'd personally try something like copr download-build, instead of the repo dance.
In each repo can be multiple builds, with multiple NVRs, and you probably want
only one of them - with specific NVR (and it doesn't have to be the latest one).

WRT repo IDs - there is one or two now; and will be many. I'd suggest you to:

 In [14]: parser = configparser.ConfigParser(strict=False)                                                                                                                                                                                    

In [15]: parser.read_file(open('group_copr-copr-epel-6.repo'))                                                                                                                                                                               

In [16]: parser.sections()[0]                                                                                                                                                                                                                
Out[16]: 'copr:copr.fedorainfracloud.org:group_copr:copr'

This issue has been migrated to GitHub: https://github.com/fedora-copr/copr/issues/1332