[bug#50072] [PATCH WIP 0/4] Add upstream updater for git-fetch origins.

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

> Sarah Morgensen schreef op ma 16-08-2021 om 12:56 [-0700]:
>> Hi Maxime,
>> 
>> Thanks for taking a look at this. :)
>> 
>> Maxime Devos <maximedevos@telenet.be> writes:
>> 
>> > Sarah Morgensen schreef op zo 15-08-2021 om 16:25 [-0700]:
>> > > * guix/git-download.scm (checkout-to-store): New procedure.
>> > > * guix/upstream.scm (guess-version-transform)
>> > > (package-update/git-fetch): New procedures.
>> > > (%method-updates): Add GIT-FETCH mapping.
>> > 
>> > Does it support packages defined like (a)
>> > 
>> > (define-public gnash
>> >   (let ((commit "583ccbc1275c7701dc4843ec12142ff86bb305b4")
>> >         (revision "0"))
>> >     (package
>> >       (name "gnash")
>> >       (version (git-version "0.8.11" revision commit))
>> >       (source (git-reference
>> >                 (url "https://example.org")
>> >                 (commit commit)))
>> >       [...])))
>> 
>> No, it doesn't.  Since the commit definition isn't part of the actual
>> package definition, the current code has no way of updating it.  It
>> would require a rewrite of the edit-in-place logic with probably a lot
>> of special-casing.
>
> Perhaps a 'surrounding-expression-location' procedure can be defined?
>
> (define (surrounding-expression-location inner-location)
>   "Determine the location of the S-expression that surrounds the S-expression
> at INNER-LOCATION, or #false if the inner S-expression is at the top-level."
>   ??? Something like 'read', but in reverse, maybe?
>   Doesn't need to support every construct, just "string without escapes" and
>   (parentheses other-things) might be good enough in practice for now)
>
> Seems tricky to implement, but it would be more robust than relying
> on conventions like ‘the surrounding 'let' can be found by moving two columns
> and two lines backwards’.  Or see another method (let&) below that is actually
> implemented ...

I think we can work incrementally.  It wouldn’t be unreasonable to start
with a ‘definition-location’ procedure that would work in a way similar
to ‘package-field-location’ (essentially ‘read’ each top-level sexp of
the file and record the location of the one that immediately precedes
the package location.)

But maybe the discussion in <https://issues.guix.gnu.org/50286> will
give us something nice.

Thanks,
Ludo’.