Re: Rebuilding a package after removing a build step
Hi Kaelyn, > Whether it does or doesn't depends on the versions of the duplicate > packages in question. If both packages have the same version, then the > command line tools will warn about the ambiguous package > specification. If the version numbers are different, then the tools > will quietly choose the "newer" version (the larger version number). My case was in neither of these well-defined situations. I had different version number strings without an obvious order relation between them. Not obvious to me at least. Here is an example (edited for focus): $ guix show -L . sbcl-websocket-driver name: sbcl-websocket-driver version: 0.2.0-0.df94496 location: gnu/packages/lisp-xyz.scm:30847:4 name: sbcl-websocket-driver version: 0.2.0-0.17ba553 location: ./kh/packages/lisp.scm:53:4 $ guix build -L . sbcl-websocket-driver /gnu/store/nd9ajz9ni395792f03ggf3jprf44cgz2-sbcl-websocket-driver-0.2.0-0.df94496 There are two definitions for sbcl-websocket-driver, differing only in the commit id. How did "guix build" choose the first one? The second one is newer, but figuring this out requires checking out the repository and analyzing its DAG. It looks like Guix picked the larger one by alphanumeric order, which is not a reasonable choice in a development context. Cheers, Konrad.
Re: Rebuilding a package after removing a build step
Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen: > $ guix show -L . sbcl-websocket-driver > name: sbcl-websocket-driver > version: 0.2.0-0.df94496 > location: gnu/packages/lisp-xyz.scm:30847:4 > It looks like Guix picked the larger one by > alphanumeric order, which is not a reasonable choice in a development > context. This is exactly the role of the number "-0." in front of the git commit; one needs to specify by hand the order of the (non-)releases, as coming from here: (define-public sbcl-websocket-driver (let ((commit "df94496ecb525d086eeada4f5875975515b7212e") (revision "0")) (package (name "sbcl-websocket-driver") (version (git-version "0.2.0" revision commit)) Andreas
Re: Rebuilding a package after removing a build step
On 2024-09-23, Andreas Enge wrote: > Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen: >> $ guix show -L . sbcl-websocket-driver >> name: sbcl-websocket-driver >> version: 0.2.0-0.df94496 >> location: gnu/packages/lisp-xyz.scm:30847:4 >> It looks like Guix picked the larger one by >> alphanumeric order, which is not a reasonable choice in a development >> context. > > This is exactly the role of the number "-0." in front of the git commit; > one needs to specify by hand the order of the (non-)releases, as coming > from here: > (define-public sbcl-websocket-driver > (let ((commit "df94496ecb525d086eeada4f5875975515b7212e") > (revision "0")) > (package > (name "sbcl-websocket-driver") > (version (git-version "0.2.0" revision commit)) Rather than picking an arbitrary incremental number, I have in the past used something based on the results from git describe... e.g. in my current checkout of guix: $ git describe --match=v1.4'*' v1.4.0-142685-gfc059c66cf e.g. 142685 commits past v1.4.0, with the commit fc059c66cf That should *usually* end up in the correct order, although sometimes there are surprises. For example, I had to specify --match otherwise it picked v1.3.0 for some inscrutible git merge-ordering reason. live well, vagrant signature.asc Description: PGP signature
Re: Rebuilding a package after removing a build step
Hi Andreas, >> It looks like Guix picked the larger one by >> alphanumeric order, which is not a reasonable choice in a development >> context. > > This is exactly the role of the number "-0." in front of the git commit; > one needs to specify by hand the order of the (non-)releases, as coming Good to know, thanks! I had been wondering what those revision numbers were good for. Manual ordering looks fine for updating packages in a given channel. But in this case, the two versions come from different channels. It's a bit hard to globally coordinate manual revision numbers across all possible channels! Cheers, Konrad.
Re: Rebuilding a package after removing a build step
While others have pointed out the workflow fix, On 2024-09-23 10:22, Konrad Hinsen wrote: If both packages have the same version, then the command line tools will warn about the ambiguous package specification. If the version numbers are different, then the tools will quietly choose the "newer" version (the larger version number). My case was in neither of these well-defined situations. It was. The second. This behaviour is stable and documented, at least under (guix)Invoking guix package, although it applies to the entire CLI. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
Re: Rebuilding a package after removing a build step
Vagrant Cascadian writes: > Rather than picking an arbitrary incremental number, I have in the past > used something based on the results from git describe... e.g. in my > current checkout of guix: > > $ git describe --match=v1.4'*' > v1.4.0-142685-gfc059c66cf > > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf > > That should *usually* end up in the correct order, although sometimes > there are surprises. For example, I had to specify --match otherwise it > picked v1.3.0 for some inscrutible git merge-ordering reason. That seems like a useful and fairly generally applicable strategy. Any reason as to why something like that (which allows for additional optional arguments such as "--match-v1.4'*'") shouldn't be used as the default (as opposed to manual revision numbers)? -- Suhail
Re: Rebuilding a package after removing a build step
On Monday, September 23rd, 2024 at 11:17 AM, Suhail Singh wrote: > > > Vagrant Cascadian vagr...@debian.org writes: > > > Rather than picking an arbitrary incremental number, I have in the past > > used something based on the results from git describe... e.g. in my > > current checkout of guix: > > > > $ git describe --match=v1.4'*' > > v1.4.0-142685-gfc059c66cf > > > > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf > > > > That should usually end up in the correct order, although sometimes > > there are surprises. For example, I had to specify --match otherwise it > > picked v1.3.0 for some inscrutible git merge-ordering reason. > > > That seems like a useful and fairly generally applicable strategy. Any > reason as to why something like that (which allows for additional > optional arguments such as "--match-v1.4'*'") shouldn't be used as the > default (as opposed to manual revision numbers)? There are a few problems with using that as the default: * Generating that version number requires the git source repository; a package definition requires a fixed version number that can be computed without ever downloading the source code, since it is part of the package metadata (though such a strategy could potentially be used by e.g. "guix refresh -u" though that would require a consistent way of setting the revision in the package definition such that the tool knows what string to change). * Using something like "git describe" to compute the revision would either be specific to packages which are built from git checkouts (i.e. built into the git-version function) or recipes for obtaining similar output would have to be written for the other version control systems for which support is desired. Closely related (but optional if the actual value of the revision is treated more loosely) is that some packages would need the "--match" flag to generate revision numbers from the correct point and the match expression would have to be updated when the "base" version for the revision counting changes. * Within git repos, "git describe" only works if there are (annotated) tags for "git describe" to base the revision number on. If the source repo doesn't use tags, the approach won't work and manual revision numbers would still be needed. Likewise, if the repo doesn't use annotated tags or uses annotated tags for purposes other than tagging official releases, the chosen tag used for the revision (even at a given commit, if an older commit is given a new tag) may not be consistent without using a sufficiently specific "--match" flag. I also want to say that the above points are primarily about automatically using "git describe" to dynamically generate a revision. I do not want to rule out or discourage ideas for ways to make use of "git describe" more convenient as a source of truth when determining what value to use for the revision. I think it could be quite useful especially for updating packages or doing local development. Cheers, Kaelyn > > -- > Suhail
Re: Rebuilding a package after removing a build step
Hi Vagrant, > Rather than picking an arbitrary incremental number, I have in the past > used something based on the results from git describe... e.g. in my > current checkout of guix: > > $ git describe --match=v1.4'*' > v1.4.0-142685-gfc059c66cf > > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf That looks very good! Not suitable for automation, as Kaelyn explained, but it could be codified as a recommendation for developers. Possibly with tool support for package developers, e.g. "guix derive-revision". Cheers, Konrad.
