Modularity UX Questions
Last month, we had a Modularity Hackfest in Boston. I wrote up a
hackfest report at the Community Blog[1] back then, which included
several open questions related to how to handle stream and profile
defaults. I'm reprinting them here on Fedora Devel for public input.
== Open Questions ==
We had some discussions throughout the course of the hackfest that
didn’t reach a clear consensus. The most contentious was around what
to do about empty profile data. There are several uncommon cases that
need to have clear UX decisions made around them.
=== A module does not have one or more of its profiles specified to be
the default. ===
The module creator has not provided a defaults object into the YAML
(in Fedora, this is done by requesting it be added by release
engineering or submitting a pull request to the fedora-module-defaults
repository). This may be intentional or unintentional. Fedora QA has
asked us if they should be treating the lack of a defaults reference
for the profile as a failure, since this is something that could be
detected during post-compose testing and reported. My personal opinion
on this case is that for modules in Fedora itself, we should indeed
treat this as a bug and require that all modules have a defaults
object that properly references a set of default profiles for any
stream included in that compose.
The open question here is what the DNF experience should be if dnf
module install modulename:modulestream is called. The current behavior
is that DNF treats this as equivalent to calling dnf module enable
modulename:modulestream (it makes the contents of this module
explicitly available, but installs nothing at that time. Feedback from
users of the RHEL 8 Beta have indicated that this is an unexpected
behavior of the install verb. They’d prefer to see DNF report an error
if install is called and results in no packages being installed. In
part, this is because it would be silently hiding the possibility that
the defaults are missing.
=== A module has explicitly set one or more of its streams to have no
default profiles ===
This is a similar case to the above, except that a conscious choice
was made by the module maintainer to say that this module has no
reasonable default packages that could be selected. (For example, it
could be a collection of popular libraries that extend a particular
programming language, but there’s no obvious subset of them that makes
sense to install. It may exist and have streams solely because it
needs to be kept in sync with the interpreter version.)
The open question is the same as the previous one: how should dnf
module install handle this case? In this particular example, it might
be more acceptable that it follows the enable fallback, since the
maintainer selected the lack of a profile explicitly. However, having
context-sensitive differences can be difficult for people to process.
=== A module has a profile that contains zero RPMs ===
In this case, a profile definition has been made in the module
metadata and it explicitly contains zero RPMs within it. Such an
example might be for compatibility: the module previously provided a
profile with that name that contained content, but it is no longer
doing so. Retaining the name may have been done to allow existing
scripts to avoid breaking. If we have a profile that contains zero
packages, should it be an error if we attempt to install it? If not,
what should the UX look like?
[1] https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/