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`
> 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-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
