On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher <sgall...@redhat.com> wrote:
> On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik <asama...@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-le...@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-le...@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-le...@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-le...@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
