[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
> This series introduces default variable bindings for the default
> gnu-build-system IMPORTED-MODULES and MODULES values.  The lack of a
> %default-gnu-modules caused enough confusion, as made apparent by
> this series.
If we're going to do this anyway, let's go big: add modules and
imported-modules to the fields of build-system and allow users to use
that.  Perhaps also add short-hands so that (default-modules gnu)
expands to (build-system-modules gnu-build-system) and likewise for
imported-modules.

Cheers

[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Maxim Cournoyer]

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
>> This series introduces default variable bindings for the default
>> gnu-build-system IMPORTED-MODULES and MODULES values.  The lack of a
>> %default-gnu-modules caused enough confusion, as made apparent by
>> this series.
> If we're going to do this anyway, let's go big: add modules and
> imported-modules to the fields of build-system and allow users to use
> that.

I don't understand; what would that look like in practice?  Isn't this
already how it works?  Build systems have #:modules and
#:imported-modules arguments, which are provided via the 'arguments'
field of a package.

> Perhaps also add short-hands so that (default-modules gnu)
> expands to (build-system-modules gnu-build-system) and likewise for
> imported-modules.

Ah!  I understand the idea now.  It feels a bit strange to me to attach
such metadata to the build-system record itself though.  At any rate, we
could discuss this separately and do it in a future iteration, perhaps?
The series posted here already has value in itself, and if we ever go to
attach this information to build system objects instead of plain
variables, we could use sed to adjust the code base.

What do yo think?

-- 
Thanks,
Maxim

[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 15:36 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
> > > This series introduces default variable bindings for the default
> > > gnu-build-system IMPORTED-MODULES and MODULES values.  The lack
> > > of a %default-gnu-modules caused enough confusion, as made
> > > apparent by this series.
> > If we're going to do this anyway, let's go big: add modules and
> > imported-modules to the fields of build-system and allow users to
> > use that.
> 
> I don't understand; what would that look like in practice?  Isn't
> this already how it works?  Build systems have #:modules and
> #:imported-modules arguments, which are provided via the 'arguments'
> field of a package.
Well, no.   The build-system record currently contains a name,
description and lowering procedure, but no "immediately helpful" data
for package writers.

> > Perhaps also add short-hands so that (default-modules gnu)
> > expands to (build-system-modules gnu-build-system) and likewise for
> > imported-modules.
> 
> Ah!  I understand the idea now.  It feels a bit strange to me to
> attach such metadata to the build-system record itself though.  At
> any rate, we could discuss this separately and do it in a future
> iteration, perhaps?
> The series posted here already has value in itself, and if we ever go
> to attach this information to build system objects instead of plain
> variables, we could use sed to adjust the code base.
> 
> What do yo think?
Hmm, at the very least I'd like to bikeshed the variable names, hence
my suggestion to encode it into the build system itself, which would
allow any name locally.  %default-anything reads weird to me, plus it's
a mouthful for imported modules.
WDYT about %gnu-build-modules and %gnu-build-system-modules, where
%gnu-build-system-modules keeps its current intent for being imported?
Alternatively we could also rename it to %gnu-build-imported-modules
with a deprecated alias.

Cheers

[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 09.10.2023 um 15:36 -0400 schrieb Maxim Cournoyer:
>> Hello,
>> 
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> > Am Montag, dem 09.10.2023 um 12:33 -0400 schrieb Maxim Cournoyer:
>> > > This series introduces default variable bindings for the default
>> > > gnu-build-system IMPORTED-MODULES and MODULES values.  The lack
>> > > of a %default-gnu-modules caused enough confusion, as made
>> > > apparent by this series.
>> > If we're going to do this anyway, let's go big: add modules and
>> > imported-modules to the fields of build-system and allow users to
>> > use that.
>> 
>> I don't understand; what would that look like in practice?  Isn't
>> this already how it works?  Build systems have #:modules and
>> #:imported-modules arguments, which are provided via the 'arguments'
>> field of a package.
> Well, no.   The build-system record currently contains a name,
> description and lowering procedure, but no "immediately helpful" data
> for package writers.
>
>> > Perhaps also add short-hands so that (default-modules gnu)
>> > expands to (build-system-modules gnu-build-system) and likewise for
>> > imported-modules.
>> 
>> Ah!  I understand the idea now.  It feels a bit strange to me to
>> attach such metadata to the build-system record itself though.  At
>> any rate, we could discuss this separately and do it in a future
>> iteration, perhaps?
>> The series posted here already has value in itself, and if we ever go
>> to attach this information to build system objects instead of plain
>> variables, we could use sed to adjust the code base.
>> 
>> What do yo think?
> Hmm, at the very least I'd like to bikeshed the variable names, hence
> my suggestion to encode it into the build system itself, which would
> allow any name locally.  %default-anything reads weird to me, plus it's
> a mouthful for imported modules.

It seems conventional to me: we have %default-subtitute-urls,
%default-channels, %default-include (thousands of matches for
'%default-' upon grepping).

> WDYT about %gnu-build-modules and %gnu-build-system-modules, where
> %gnu-build-system-modules keeps its current intent for being imported?
> Alternatively we could also rename it to %gnu-build-imported-modules
> with a deprecated alias.

People have been adding %gnu-build-system-modules to #:modules
erroneously.  Not renaming that would ensure this keeps happening.
Having 'imported-modules' in the name seems like it'd make things a bit
easier to remember; thus, I think the proposed naming is adequate?

-- 
Thanks,
Maxim

[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 21:31 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > Hmm, at the very least I'd like to bikeshed the variable names,
> > hence my suggestion to encode it into the build system itself,
> > which would allow any name locally.  %default-anything reads weird
> > to me, plus it's a mouthful for imported modules.
> 
> It seems conventional to me: we have %default-subtitute-urls,
> %default-channels, %default-include (thousands of matches for
> '%default-' upon grepping).
Fair enough, but in the cases you've named it's still %default for more
than one build system.  Or do you by extension want %default-glib-or-
gtk-imported-modules?  That's quite a mouthful imho without any
additional semantics.

> > WDYT about %gnu-build-modules and %gnu-build-system-modules, where
> > %gnu-build-system-modules keeps its current intent for being
> > imported?
> > Alternatively we could also rename it to %gnu-build-imported-
> > modules
> > with a deprecated alias.
> 
> People have been adding %gnu-build-system-modules to #:modules
> erroneously.  Not renaming that would ensure this keeps happening.
> Having 'imported-modules' in the name seems like it'd make things a
> bit easier to remember; thus, I think the proposed naming is
> adequate?
Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
is better even with that reasoning.

Cheers

[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 09.10.2023 um 21:31 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana,
>> 
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> > Hmm, at the very least I'd like to bikeshed the variable names,
>> > hence my suggestion to encode it into the build system itself,
>> > which would allow any name locally.  %default-anything reads weird
>> > to me, plus it's a mouthful for imported modules.
>> 
>> It seems conventional to me: we have %default-subtitute-urls,
>> %default-channels, %default-include (thousands of matches for
>> '%default-' upon grepping).
> Fair enough, but in the cases you've named it's still %default for more
> than one build system.  Or do you by extension want %default-glib-or-
> gtk-imported-modules?  That's quite a mouthful imho without any
> additional semantics.

That's what I was thinking to in the future yes; add
%default-glib-or-gtk-imported-modules as well as
%default-glib-or-gtk-modules, %default-cmake-imported-modules and
%default-cmake-modules, etc.

The variable names may be somewhat long, but they are not used often and
they should be easy to auto-complete.

>> > WDYT about %gnu-build-modules and %gnu-build-system-modules, where
>> > %gnu-build-system-modules keeps its current intent for being
>> > imported?
>> > Alternatively we could also rename it to %gnu-build-imported-
>> > modules
>> > with a deprecated alias.
>> 
>> People have been adding %gnu-build-system-modules to #:modules
>> erroneously.  Not renaming that would ensure this keeps happening.
>> Having 'imported-modules' in the name seems like it'd make things a
>> bit easier to remember; thus, I think the proposed naming is
>> adequate?
> Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
> is better even with that reasoning.

So we'd use for example %glib-or-gtk-build-imported-modules?  The
difference is small to what I proposed (swap the leading default for an
in-middle 'build' -- 2 characters), so I don't think your 'mouthful'
argument holds, but I don't have much of an issue with it, except
perhaps that 'build' is not directly attached to the module namespace,
which is (guix build-systems gnu) for example.

I still prefer my naming, but yeah, we're choosing the color of the bike
shed :-).  If others could tip in, that may help decide, otherwise I'd
prefer leaving it as-is.  Does that sound reasonable?

-- 
Thanks,
Maxim

[bug#66426] [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Maxim Cournoyer]

Hello,

[...]

>>> People have been adding %gnu-build-system-modules to #:modules
>>> erroneously.  Not renaming that would ensure this keeps happening.
>>> Having 'imported-modules' in the name seems like it'd make things a
>>> bit easier to remember; thus, I think the proposed naming is
>>> adequate?
>> Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
>> is better even with that reasoning.
>
> So we'd use for example %glib-or-gtk-build-imported-modules?  The
> difference is small to what I proposed (swap the leading default for an
> in-middle 'build' -- 2 characters), so I don't think your 'mouthful'
> argument holds, but I don't have much of an issue with it, except
> perhaps that 'build' is not directly attached to the module namespace,
> which is (guix build-systems gnu) for example.
>
> I still prefer my naming, but yeah, we're choosing the color of the bike
> shed :-).  If others could tip in, that may help decide, otherwise I'd
> prefer leaving it as-is.  Does that sound reasonable?

I just realized that the whole series had been sent mistakenly to
another series (seems I messed up using 'mumi send'):
<https://issues.guix.gnu.org/65924#18>.

I did spot a couple errors in that series that I've resolved locally.

If nobody has further concerns, I'll merge it later today to the
core-updates branch.

-- 
Thanks,
Maxim

bug#66426: [PATCH 00/65] Export %default-gnu-imported-modules and %default-gnu-modules.

[Maxim Cournoyer]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hello,
>
> [...]
>
>>>> People have been adding %gnu-build-system-modules to #:modules
>>>> erroneously.  Not renaming that would ensure this keeps happening.
>>>> Having 'imported-modules' in the name seems like it'd make things a
>>>> bit easier to remember; thus, I think the proposed naming is
>>>> adequate?
>>> Perhaps, but I think %gnu-build-modules and %gnu-build-imported-modules
>>> is better even with that reasoning.
>>
>> So we'd use for example %glib-or-gtk-build-imported-modules?  The
>> difference is small to what I proposed (swap the leading default for an
>> in-middle 'build' -- 2 characters), so I don't think your 'mouthful'
>> argument holds, but I don't have much of an issue with it, except
>> perhaps that 'build' is not directly attached to the module namespace,
>> which is (guix build-systems gnu) for example.
>>
>> I still prefer my naming, but yeah, we're choosing the color of the bike
>> shed :-).  If others could tip in, that may help decide, otherwise I'd
>> prefer leaving it as-is.  Does that sound reasonable?
>
> I just realized that the whole series had been sent mistakenly to
> another series (seems I messed up using 'mumi send'):
> <https://issues.guix.gnu.org/65924#18>.
>
> I did spot a couple errors in that series that I've resolved locally.
>
> If nobody has further concerns, I'll merge it later today to the
> core-updates branch.

I've now done so.  Thanks for the review/comments!

-- 
Thanks,
Maxim