#:modules and #:imported-modules, and more

#:modules and #:imported-modules, and more

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 4377 bytes --]

Hello Guix.


Table of Contents
_________________

1. My understanding
2. #:extra-modules, #:extra-imported-modules
3. %...-build-system-modules
4. %default-modules
5. Other comments
.. 1. What are the reasons for the naming scheme of build systems?
6. Conclusion


1 My understanding
==================

  In the process of fixing crashes of libreoffice and netsurf (patches
  coming soon), I was trying to understand the difference between
  #:modules and #:imported-modules.  My conclusion is that the former
  are modules that are (use-modules)-ed automatically, while the latter
  are modules that are made available and can be (use-modules)-ed if
  desired.

  If one wants to add some modules, the way it is done, for
  gnu-build-system, is like this:

  ,----
  | #:imported-modules `((some module)
  |                      ,@gnu-build-system-modules)
  `----

  Is that summary correct?

  Assuming it is, I would like to propose few changes.  I am willing to
  supply the implementation(s), but thought I should discuss it first in
  order not to waste time if it would be a no-go.  They would be done in
  roughly this order over multiple patch series to allow smooth
  transition.


2 #:extra-modules, #:extra-imported-modules
===========================================

  As seen in the example above, currently there is a need to manually
  merge the list of additional modules with the original one.  Failing
  to use the correct base can lead to issues (like crash in netsurf).

  I would like to propose adding two new fields into the build system,
  `#:extra-modules' and `#:extra-imported-modules'.  Those would be
  automatically appended to the `#:modules' and `#:imported-modules',
  removing the need to merge the lists in the package definition.
  Therefore the example above would turn into:

  ,----
  | #:extra-imported-modules '((some module))
  `----

  The original fields would still be available, so full control would be
  possible, if needed.

  There currently seems to be ~276 occurrences of
  `-build-system-modules' in the gnu/packages directory, and vast
  majority of them would be removed.


3 %...-build-system-modules
===========================

  This variable seems misnamed, since it should be used with
  `#:imported-modules', so once the above is done (and the usage of it
  drops down), I would like to rename it to
  `%...-build-system-imported-modules'.


4 %default-modules
==================

  Situation with `#:modules' is more interesting, since there is no
  common pattern.  Some build systems have `%default-modules'
  (non-exported), some just hard-code the list.  In the step above the
  binding was released, so I would like to unify the build systems by
  reusing as public `%...-build-system-modules', which would be used as
  default for `#:modules' in all build systems.

  These steps are somewhat independent, but at least this last one I
  would think would be useful.  Albeit without the previous ones
  different name would have to be used.


5 Other comments
================

5.1 What are the reasons for the naming scheme of build systems?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  It seems that all the build systems use a prefix-based naming scheme,
  so `gnu-build-system', `meson-build-system' and such.  I am curious
  what is the reason for that?  Since Guile modules support `#:prefix',
  would it not be a cleaner choice?

  So I could have something like:

  ,----
  | (define-module (gnu packages foo)
  |   #:use-module ((guix build-system gnu)    #:prefix gnu)
  |   #:use-module ((guix build-system python) #:prefix python))
  |   ...)
  |
  | (define-public bar
  |   (package
  |     ...
  |     (build-system gnu:build-system)))
  |
  | (define-public baz
  |   (package
  |     ...
  |     (build-system python:build-system)))
  `----

  That, given there is a built-in support in the language, seems
  somewhat cleaner.  And could possibly make introspection easier
  (maybe?).  Could someone enlighten me regarding the reasons for the
  current implementation?


6 Conclusion
============

  Thank you for considering this proposal, and thank you in advance for
  any helpful insight you are willing to provide.



Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: #:modules and #:imported-modules, and more

[Ludovic Courtès]

Hello!

Tomas Volf <~@wolfsden.cz> skribis:

>   As seen in the example above, currently there is a need to manually
>   merge the list of additional modules with the original one.  Failing
>   to use the correct base can lead to issues (like crash in netsurf).
>
>   I would like to propose adding two new fields into the build system,
>   `#:extra-modules' and `#:extra-imported-modules'.  Those would be
>   automatically appended to the `#:modules' and `#:imported-modules',
>   removing the need to merge the lists in the package definition.
>   Therefore the example above would turn into:

As a rule of thumb, I personally always avoid the #:extra-things
pattern, instead letting users pass #:things in their entirety and
documenting the default value.

I believe (1) this is clearer (when I see “extra”, I’m always like “extra
compared to what?”), and (2) it gives more control over the things in
question (since one can also remove stuff from the default value).

So yes, that’s a bit more boilerplate when all you want is import one
additional module, but I think it’s overall a better interface than
#:extra.

I hope this makes sense!

Ludo’.

Re: #:modules and #:imported-modules, and more

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On 2024-01-09 23:49:33 +0100, Ludovic Courtès wrote:
> Hello!
>
> Tomas Volf <~@wolfsden.cz> skribis:
>
> >   As seen in the example above, currently there is a need to manually
> >   merge the list of additional modules with the original one.  Failing
> >   to use the correct base can lead to issues (like crash in netsurf).
> >
> >   I would like to propose adding two new fields into the build system,
> >   `#:extra-modules' and `#:extra-imported-modules'.  Those would be
> >   automatically appended to the `#:modules' and `#:imported-modules',
> >   removing the need to merge the lists in the package definition.
> >   Therefore the example above would turn into:
>
> As a rule of thumb, I personally always avoid the #:extra-things
> pattern, instead letting users pass #:things in their entirety and
> documenting the default value.
>
> I believe (1) this is clearer (when I see “extra”, I’m always like “extra
> compared to what?”), and (2) it gives more control over the things in
> question (since one can also remove stuff from the default value).

Well you could still remove the default stuff, since the "non-extra" would not
be going anywhere.

>
> So yes, that’s a bit more boilerplate when all you want is import one
> additional module, but I think it’s overall a better interface than
> #:extra.
>
> I hope this makes sense!

I see your point.  Not sure I fully agree, but do understand what you mean and
will not push on it further.

However even in that light, I still consider the 3 and 4 to be worth
considering.  Aaand even without 3, at least doing 4 in some shape or form would
be in my opinion useful.  Current situation is bit... copy&pasty.

Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: #:modules and #:imported-modules, and more

[Ludovic Courtès]

Hi!

Tomas Volf <~@wolfsden.cz> skribis:

> However even in that light, I still consider the 3 and 4 to be worth
> considering.  Aaand even without 3, at least doing 4 in some shape or form would
> be in my opinion useful.  Current situation is bit... copy&pasty.

In ‘core-updates’, commit 9e4ce281dbd92e3c52b831824ebb1f77023c960c by
Maxim should address these concerns (IIUC) by distinguishing and
renaming the variables for the default set of imported and in-scope
modules for ‘gnu-build-system’.

Is that one of the things you had in mind?

Thanks,
Ludo’.

Re: #:modules and #:imported-modules, and more

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

On 2024-01-10 11:23:22 +0100, Ludovic Courtès wrote:
> Hi!
> 
> Tomas Volf <~@wolfsden.cz> skribis:
> 
> > However even in that light, I still consider the 3 and 4 to be worth
> > considering.  Aaand even without 3, at least doing 4 in some shape or form would
> > be in my opinion useful.  Current situation is bit... copy&pasty.
> 
> In ‘core-updates’, commit 9e4ce281dbd92e3c52b831824ebb1f77023c960c by
> Maxim should address these concerns (IIUC) by distinguishing and
> renaming the variables for the default set of imported and in-scope
> modules for ‘gnu-build-system’.
> 
> Is that one of the things you had in mind?

Ah, yes, thank you for pointing that commit out, pretty much that, just for all
the build systems (it seems only gnu-build-system was modified on core-updates).

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]