Re: Guile 3.0

[Luca Fascione]

I would like to bring up an option that I'd expect fair few of you will
_really_ not like.
I'm doing this not because I necessarily believe it to be a
particularly good way forward,
rather because I feel it is sometimes useful to articulate in words why an
"obviously awful idea" is, in fact, awful. Or maybe it isn't

So here it goes: what if we shipped the guile source? (I mean, in a
subdirectory of lilypond's source)

At a quick look, it doesn't seem to be particularly hard to build
(comparatively speaking),
and its dependencies are mostly fairly benign stuff that appear to be
runtime dependencies anyways
(like libgc and such, point being, you need to install all that when you
install guile anyways; if I read it right only 'gnu-sed' is a compile-only
dependency).

One benefit I see is that we could ship it as vX.Y.X + a single patch, so
that it fundamentally documents what we've done to it (albeit git history
could also serve this purpose).
As an example, it seems to me that for 3.0.8 we'd want Jean's patch about
the line number reporting in errors, and I recall a discussion about
storing precompiled scripts that
at that point we might consider fixing in the guile source ourselves. I am
confused in this second whether this compiled scripts issue is problematic
in 2.2.x also or not.

I'm saying this because it seems to me that, different from python, there's
no real collaboration/interaction between the
guile installed on one's system and the interpreter inside lilypond, and
this would completely decouple us from the rest of
the distribution's concerns about which version of guile to ship (and seen
some distro use lilypond as an element of deciding the version
it's possible they wouldn't ship it at all if it wasn't for lilypond?)

Of course I'm seeing this as a possibly viable "lesser evil" kinda approach
only because the evidence we have is that the project activity is minimal
and their interest in addressing our needs (as exemplified by the post
Jean's shared) is also near-zero.
Which implies: we unblock ourselves without taking on this huge burden of
staying caught-up with the upstream
(and as an added "bonus" we also can decide to apply someone else's patches
should they fix a problem we have)

L

On Sun, May 22, 2022 at 5:42 PM David Kastrup <dak@gnu.org> wrote:

> Jean Abou Samra <jean@abou-samra.fr> writes:
>
> > Le 22/05/2022 à 17:04, David Kastrup a écrit :
> >> [...]
> >>> Also see
> >>>
> >>> guile$ git shortlog -ns --since="2 months ago"
> >>>       2  Timothy Sample
> >>>       1  Ludovic Courtès
> >>>       1  Mikael Djurfeldt
> >> Well, it's the stable release branch.
> >
> >
> > What would be the development branch?
> >
> > $ git branch --show-current
> > main
> > $ git shortlog -ns v3.0.8..HEAD
> >      6  Ludovic Courtès
> >      2  Timothy Sample
> >      1  Andy Wingo
> >      1  Mikael Djurfeldt
> >      1  Rob Browning
> >      1  Sergei Trofimovich
> >      1  Vijay Marupudi
>
> I am not in control of Guile's development models or lack thereof.  I
> simply reported the information on their website that distributors would
> go by.
>
> >> [...]
> >> No, Guile is in trouble then.  I mean, it is in trouble now.  But if
> >> distributors can easily do version-hopping on their own initiative and
> >> end up with one version of Guile they are going to ship for their whole
> >> distro, it would be good if that does not end up in making LilyPond
> >> disappear.  That's all.
> >>
> >> What we _recommend_ and use ourselves is an entirely different matter.
> >
> >
> > OK, but in that case, what is your request concretely?
> > Current LilyPond master works with Guile 3.0.
>
> That's essentially all.  I wasn't sure of that from the discussion and
> from what I remembered from previous exchanges.
>
> > Do you want to add it to the CI?
>
> I am afraid that I am not tracking the development of Guile and the CI
> resources of LilyPond well enough to venture any opinion that would be
> more qualified than that of the current developers.
>
> --
> David Kastrup
>
>

-- 
Luca Fascione