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/
On Mon, Apr 1, 2019 at 6:58 PM Stephen Gallagher sgallagh@redhat.com wrote:
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.
When a packager doesn't provide the YAML defaults file at all, I'd assume it could have been unintentional and notified them about that fact. However, I wouldn't prevent the module to get to the compose or anything — just let them know so they can decide.
How DNF should behave? Considering there is no default stream nor default profile, I'd suggest the following command to fail with an appropriate error message:
$ dnf module install modulename:stream
I'd strongly encourage DNF to suggest how to move forward, notifying the user there is no default profile defined for this module and that they either need to specify one in the install command:
$ dnf module install modulename:stream/profile
... or to enable the module in order to consume the packages directly by the following command:
$ dnf module enable modulename:stream $ dnf install packagename
As Modularity is a new technology, I personally wouldn't be afraid of longer error messages — within reason of course — giving the user guidance.
=== 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.
I assume the difference here is that the packager has provided the YAML defaults file, but haven't specified a default profile as opposed to not providing that file at all?
If that's true, I would strongly prefer consistency and fail on an install command without having a stream specified, and give the user guidance in an error message as above.
=== 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?
This seams as a strange, yet possible choice for the packager to make.
I do not have a strong opinion on this one. I'd probably suggest to not be too clever and let them have that choice, and make the install command work without installing any RPMs, and possibly emit a warning to the user about the fact.
[1] https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik asamalik@redhat.com wrote:
When a packager doesn't provide the YAML defaults file at all, I'd assume it could have been unintentional and notified them about that fact. However, I wouldn't prevent the module to get to the compose or anything — just let them know so they can decide.
How DNF should behave? Considering there is no default stream nor default profile, I'd suggest the following command to fail with an appropriate error message:
$ dnf module install modulename:stream
I'd strongly encourage DNF to suggest how to move forward, notifying the user there is no default profile defined for this module and that they either need to specify one in the install command:
$ dnf module install modulename:stream/profile
... or to enable the module in order to consume the packages directly by the following command:
$ dnf module enable modulename:stream $ dnf install packagename
As Modularity is a new technology, I personally wouldn't be afraid of longer error messages — within reason of course — giving the user guidance.
Yeah, I think if no default object exists in the metadata, `dnf module install modulename:stream` should probably not install anything and instead prompt them to select a profile explicitly (ideally listing the available options or suggesting `dnf enable modulename:stream`).
=== 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.
I assume the difference here is that the packager has provided the YAML defaults file, but haven't specified a default profile as opposed to not providing that file at all?
No, this is "the packager has provided a YAML defaults file like:
``` document: modulemd-defaults version: 1 data: modified: 201904020000 module: somemodule stream: 1.0 profiles: 1.0: [ ] ```
See that the '1.0' stream is listed as having an empty set of default profiles. Thus, a conscious decision has been made that no default makes sense for this stream. What do we do here?
I'm leaning towards treating it like the above. DNF should provide a helpful error suggesting available profiles or `dnf enable module:stream`
If that's true, I would strongly prefer consistency and fail on an install command without having a stream specified, and give the user guidance in an error message as above.
=== 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?
This seams as a strange, yet possible choice for the packager to make.
I do not have a strong opinion on this one. I'd probably suggest to not be too clever and let them have that choice, and make the install command work without installing any RPMs, and possibly emit a warning to the user about the fact.
Yeah, I'm leaning towards making a zero-package profile be a validation error in libmodulemd.
[1] https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik asamalik@redhat.com wrote:
When a packager doesn't provide the YAML defaults file at all, I'd
assume it could have been unintentional and notified them about that fact. However, I wouldn't prevent the module to get to the compose or anything — just let them know so they can decide.
How DNF should behave? Considering there is no default stream nor
default profile, I'd suggest the following command to fail with an appropriate error message:
$ dnf module install modulename:stream
I'd strongly encourage DNF to suggest how to move forward, notifying the
user there is no default profile defined for this module and that they either need to specify one in the install command:
$ dnf module install modulename:stream/profile
... or to enable the module in order to consume the packages directly by
the following command:
$ dnf module enable modulename:stream $ dnf install packagename
As Modularity is a new technology, I personally wouldn't be afraid of
longer error messages — within reason of course — giving the user guidance.
Yeah, I think if no default object exists in the metadata, `dnf module install modulename:stream` should probably not install anything and instead prompt them to select a profile explicitly (ideally listing the available options or suggesting `dnf enable modulename:stream`).
=== 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.
I assume the difference here is that the packager has provided the YAML
defaults file, but haven't specified a default profile as opposed to not providing that file at all?
No, this is "the packager has provided a YAML defaults file like:
document: modulemd-defaults version: 1 data: modified: 201904020000 module: somemodule stream: 1.0 profiles: 1.0: [ ]See that the '1.0' stream is listed as having an empty set of default profiles. Thus, a conscious decision has been made that no default makes sense for this stream. What do we do here?
I'm leaning towards treating it like the above. DNF should provide a helpful error suggesting available profiles or `dnf enable module:stream`
Ah, got it!
Still strongly prefer consistent behaviour of this and the above — failing and giving the user a guidance.
If that's true, I would strongly prefer consistency and fail on an
install command without having a stream specified, and give the user guidance in an error message as above.
=== 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?
This seams as a strange, yet possible choice for the packager to make.
I do not have a strong opinion on this one. I'd probably suggest to not
be too clever and let them have that choice, and make the install command work without installing any RPMs, and possibly emit a warning to the user about the fact.
Yeah, I'm leaning towards making a zero-package profile be a validation error in libmodulemd.
Actually, that sounds very reasonable.
[1]
https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Hello, please could you tell me if any decisions have been made on how this thread is going to be handled? Is it defined somewhere, where I could read, what the behaviour will be like?
Thanks.
On Tue, Apr 2, 2019 at 3:19 PM Adam Samalik asamalik@redhat.com wrote:
On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik asamalik@redhat.com wrote:
When a packager doesn't provide the YAML defaults file at all, I'd
assume it could have been unintentional and notified them about that fact. However, I wouldn't prevent the module to get to the compose or anything — just let them know so they can decide.
How DNF should behave? Considering there is no default stream nor
default profile, I'd suggest the following command to fail with an appropriate error message:
$ dnf module install modulename:stream
I'd strongly encourage DNF to suggest how to move forward, notifying
the user there is no default profile defined for this module and that they either need to specify one in the install command:
$ dnf module install modulename:stream/profile
... or to enable the module in order to consume the packages directly
by the following command:
$ dnf module enable modulename:stream $ dnf install packagename
As Modularity is a new technology, I personally wouldn't be afraid of
longer error messages — within reason of course — giving the user guidance.
Yeah, I think if no default object exists in the metadata, `dnf module install modulename:stream` should probably not install anything and instead prompt them to select a profile explicitly (ideally listing the available options or suggesting `dnf enable modulename:stream`).
=== 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.
I assume the difference here is that the packager has provided the YAML
defaults file, but haven't specified a default profile as opposed to not providing that file at all?
No, this is "the packager has provided a YAML defaults file like:
document: modulemd-defaults version: 1 data: modified: 201904020000 module: somemodule stream: 1.0 profiles: 1.0: [ ]See that the '1.0' stream is listed as having an empty set of default profiles. Thus, a conscious decision has been made that no default makes sense for this stream. What do we do here?
I'm leaning towards treating it like the above. DNF should provide a helpful error suggesting available profiles or `dnf enable module:stream`
Ah, got it!
Still strongly prefer consistent behaviour of this and the above — failing and giving the user a guidance.
If that's true, I would strongly prefer consistency and fail on an
install command without having a stream specified, and give the user guidance in an error message as above.
=== 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?
This seams as a strange, yet possible choice for the packager to make.
I do not have a strong opinion on this one. I'd probably suggest to not
be too clever and let them have that choice, and make the install command work without installing any RPMs, and possibly emit a warning to the user about the fact.
Yeah, I'm leaning towards making a zero-package profile be a validation error in libmodulemd.
Actually, that sounds very reasonable.
[1]
https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Dne 01. 04. 19 v 18:57 Stephen Gallagher napsal(a):
=== 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?
I can have empty "default" profile - for compatibility reasons
* some application need to dnf module enable *and* dnf module install (with default profile) - yet I do not want actually anything to be installed, I just want to have packages available. * I have e.g. server/workstation profile - there is no real default, but some application requires default, so I can create empty default.
Miroslav
=== A module does not have one or more of its profiles specified to be
the default. ===
Here, I would expect that DNF will finish with error, advising the user to select a profile specifically, such as using "dnf module install <module>:<stream>/<profile>".
=== A module has explicitly set one or more of its streams to have no
default profiles ===
Here, I could imagine that such a module would be marked "special".
Marking a module "special" would clearly tell QA that special behaviour is intented (empty profile or something similar). The DNF either should not list them in "dnf module list" or if listed they should have a visible distinction (such as "s") or something like that. We could utilize the difference between "dnf module list" and "dnf module list --all", that currently do the same job, so that "dnf module list" would only show installable modules, while "dnf module list --all" would list all modules, as the option suggests. If someone attempted to install a special module, DNF should not proceed anyhow and warn about that.
=== A module has a profile that contains zero RPMs ===
See above. This should be a typical example of a "special" module.
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/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Apr 2, 2019 at 8:42 AM Lukas Ruzicka lruzicka@redhat.com wrote:
=== A module does not have one or more of its profiles specified to be
the default. ===
Here, I would expect that DNF will finish with error, advising the user to select a profile specifically, such as using "dnf module install <module>:<stream>/<profile>".
=== A module has explicitly set one or more of its streams to have no
default profiles ===
Here, I could imagine that such a module would be marked "special".
Marking a module "special" would clearly tell QA that special behaviour is intented (empty profile or something similar). The DNF either should not list them in "dnf module list" or if listed they should have a visible distinction (such as "s") or something like that. We could utilize the difference between "dnf module list" and "dnf module list --all", that currently do the same job, so that "dnf module list" would only show installable modules, while "dnf module list --all" would list all modules, as the option suggests. If someone attempted to install a special module, DNF should not proceed anyhow and warn about that.
I think that would be far more confusing than the approach I just suggested. Note that `dnf module list` will already show which profiles are the default. If there are none, there's no need for an additional identifier.
But I think I'm coming around to "it should reject the request and advise you to use `enable` or a specific profile";
-
Adam Samalik -
Lukas Ruzicka -
Miroslav Suchý -
Stephen Gallagher