On Tue, Oct 19, 2021 at 3:36 PM David Moreau-Simard <dmsimard@redhat.com> wrote:
(replying from hyperkitty as I'm not subscribed to fedora-devel, hopefully this works)

> How about this:
>
>   *  Have a single ansible dist git repo with a single spec file
>   *  The source would be https://pypi.org/project/ansible/

There couldn't be a single source because 'ansible' and 'ansible-core' are two distinct packages:
- https://pypi.org/project/ansible/
- https://pypi.org/project/ansible-core/

Since >=2.10.x, 'ansible' is mostly composed of the ansible_collections directory with a selection of included collections whereas 'ansible-core' provides the CLI, runtime, builtin modules/plugins, etc.

>   *  Produce multiple RPM packages from this spec file
>      *  ansible-core
>      *  one RPM package for each collection in the pypi ansible package -
> these could be created programatically in the spec file using LUA or other
> spec file automation to create separate package, documentation, files,
> Requires, etc. for each collection package
>      * a package called "ansible" which is essentially a meta-package which
> simply does a "Requires: ansible-core" and also "Requires" every
> collection
> package
>
> That way, there is a single source for any/all combinations of ansible-core
> + collection rpms, or the entire ansible containing everything.
>
> One downside is that this restricts the ability to produce fixes or
> upgrades for individual collections independently of the rest of the
> Ansible packages. But I think that's only a problem if
>
>  * the independent collections change frequently
>  * the https://pypi.org/project/ansible lags behind and doesn't keep up
> with the collections

In fact, we first considered proposing something that was similar to what you suggest -- an ansible package that pulls in individually packaged collections as well as ansible-core - before settling on the change at https://fedoraproject.org/wiki/Changes/Ansible5.

We concluded that it would be hard to do in practice because:
- Ansible 5 will ship with ~95 individual collections (https://github.com/ansible-community/ansible-build-data/blob/main/5/ansible.in)
- Of these 95 collections, there's only about a dozen that are already packaged (I wrote down some notes here: https://hackmd.io/iAloYlTQQ3e-yi99w_o54A)
- The versions of individually packaged collections could diverge from those shipped inside the 'ansible' package (ex: https://github.com/ansible-community/ansible-build-data/blob/main/5/ansible-5.0.0a2.deps)
- Even considering we develop tooling and automation around the process, it would still be error prone and a lot of work without mentioning the administrative overhead of maintaining 95+ packages

In short: it would require a non-negligible amount of effort to package each individual collection, keep them updated while in sync with the versions that the upstream package ships without conflicts.

ok


The change that is currently proposed is somewhat of a middle ground to unblock the situation and allow us to move forward:
- Users who aren't interested in the "batteries included" or "kitchen sink" package can install ansible-core (note that ansible-core by itself contains far less modules/plugins than ansible 2.9.x as those were split out >=2.10.x)

Indeed - https://docs.ansible.com/ansible-core/2.11/collections/ansible/builtin/index.html (but note that this list doesn't include filters, or jinja2 built-ins)

- Users of the 'ansible-core' package can install collections from Ansible galaxy or from individually packaged collections
- Users of the 'ansible' package can install collections from Ansible galaxy or from individually packaged collections and they will have precedence over the ones installed by 'ansible' by default
- It doesn't prevent collections from being individually packaged if a maintainer wants to do so

Hopefully that makes sense and I'm happy to answer questions.

Yes, this makes sense.

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure