[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we find a better idiom for unversioned packages?
From: |
Xinglu Chen |
Subject: |
Re: Can we find a better idiom for unversioned packages? |
Date: |
Wed, 01 Sep 2021 14:11:59 +0200 |
On Tue, Aug 31 2021, Maxime Devos wrote:
> Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]:
>> Hello Guix,
>>
>> Currently, there are about 1500 packages defined like this:
>>
>> --8<---------------cut here---------------start------------->8---
>> (define-public sbcl-feeder
>> (let ((commit "b05f517d7729564575cc809e086c262646a94d34")
>> (revision "1"))
>> (package
>> [...])))
>> --8<---------------cut here---------------end--------------->8---
>>
>> I feel like there are some issues with this idiom (in no particular
>> order):
>>
>> 1. When converting between this idiom and regularly versioned packages,
>> the git diff shows the whole package changing because of the indentation
>> change.
>>
>> 2. We cannot get at the source location for the definition of 'commit' or
>> 'revision'. This would be useful for updating these packages with `guix
>> refresh -u`. There is a proposed patch [0] to work around this, but it
>> *is* a workaround.
>>
>> 3. Packages inheriting from it lose the definitions. For actual fields,
>> we have e.g. `(package-version this-package)`, but we have no equivalent
>> for these.
>>
>> 4. Horizontal space is at a premium, and an extra two spaces here and
>> there add up. (Personally, I think we could do with a
>> define-public-package macro to save another two spaces, but that's for
>> another day...)
>>
>> 5. The closest thing we have to a standardized way of generating
>> versions for these packages is `(version (git-version "0.0.0" revision
>> commit))`. We can do better than that boilerplate.
>
> Suggestion: extend the 'version' field. More specifically,
> introduce a new record <full-version>, like this:
>
> (define-record-type* <extended-version> extended-version make-extended-version
> extended-version? this-version
> ;; something like 1.2.3 (TODO better name)
> (base extended-version-base)
> (revision extended-version-revision)
> (commit extended-version-commit))
>
> (define (version->string version)
> (match version
> ((? string?) version)
> (($ <extended-version> ...) code from original git-version and
> hg-version)))
>
> ;; TODO:
> ;; adjust git-file-name and hg-file-name to accept <extended-version> records
> ;; (as well as the ‘old style’ for compatibility)
>
> To be used like:
>
> (define-public sbcl-feeder
> (name "sbcl-feeder")
> (version (extended-version
> (base "1.0.0")
> (revision 1)
> (commit "b05f517d7729564575cc809e086c262646a94d34")))
> (source
> (origin
> (method git-fetch)
> (uri (git-reference ...)
> (url ...)
> ;; git-reference needs to be extended to retrieve the commit from
> the version
> (version version)))
> (file-name (git-file-name "feeder" version))
> (sha256 ...)))
> [...])
How will this work for SVN and CVS? I am not familiar with either, but
I know that SVN has its own ‘revision’ thing.
signature.asc
Description: PGP signature
- Re: Can we find a better idiom for unversioned packages?, (continued)
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/01
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/01
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/02
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/02
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Xinglu Chen, 2021/09/03
- Re: Can we find a better idiom for unversioned packages?, Leo Famulari, 2021/09/04
- Re: Can we find a better idiom for unversioned packages?, Ludovic Courtès, 2021/09/08
Re: Can we find a better idiom for unversioned packages?,
Xinglu Chen <=
Re: Can we find a better idiom for unversioned packages?, Liliana Marie Prikler, 2021/09/01
Re: Can we find a better idiom for unversioned packages?, Jonathan McHugh, 2021/09/01
Re: Can we find a better idiom for unversioned packages?, Liliana Marie Prikler, 2021/09/01
Re: Can we find a better idiom for unversioned packages?, Maxime Devos, 2021/09/02