From: Phil Beadling <phil@beadling.co.uk>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: --with-source version not honored?
Date: Sun, 24 Oct 2021 13:11:13 +0100 [thread overview]
Message-ID: <CAOvsyQscDyBjqZrD7uzCrOYsaVh+GL1CCD35Qubwg_W8jKvejQ@mail.gmail.com> (raw)
In-Reply-To: <87mtn0f45b.fsf@beadling.co.uk>
[-- Attachment #1: Type: text/plain, Size: 3744 bytes --]
I was able to write a short manifest that avoided the overwriting of the
original "foobarpy" package in my case, and instead cleanly replace it with
a newer version specified using "with-source".
By setting, for example, GUIX_FOOBAR_VERSION=1.23 and
GUIX_TEST_PACKAGE=my-package - I can now create an environment which builds
the version of foobarpy I want from an https link generated from
GUIX_FOOBAR_VERSION, and then create a modified version of "my-package"
with foobarpy replaced, rather than overwritten.
This is much better than my original hack, but it's still not recursive so
whilst it does rebuild my-package with the new version of foobarpy as a
propagated input, it isn't rebuilding the whole dependency tree - other
inputs to my-package could also depend on foobarpy, and should be rebuilt
too - so what I've done is more of a graft, buthappens to be good enough
for my specific use case (the foobarpy is not used anywhere else in my
case).
Anyway thought I'd share this here as a template for simple non-recursive
cases. I suspect it's not a massive effort to make it recursive, when I
have a moment I'll have a think about that too. Any thoughts on how to
improve are welcome!
(use-modules (guix transformations) ;; options->transformation
(guix packages) ;; package/inherit
(srfi srfi-1) ;; fold
(srfi srfi-98)) ;; get-environment-variable
(define (generate-foobar-link version)
(string-append "https://packages.foobar.com/"
(substring version 0 3) "/foobar"
version "_linux64.tar.gz"))
(define transform
;; The package transformation procedure.
(let* ((foobar-version (get-environment-variable "GUIX_FOOBAR_VERSION"))
(foobar-link (string-append
"foobarpy@" foobar-version
"=" (generate-foobar-link foobar-version))))
(format #t "~%Setting Foobar Version: ~a~%" foobar-version)
(options->transformation
`((with-source . ,foobar-link)))))
(define my-foobar-package (transform (specification->package "foobarpy")))
(define-public my-package-with-my-foobar
(let* ((test-package-string (get-environment-variable
"GUIX_TEST_PACKAGE"))
(test-package (specification->package test-package-string)))
(package/inherit test-package
(propagated-inputs
`(("foobarpy" ,my-foobar-package)
,@(fold alist-delete (package-propagated-inputs test-package)
'("foobarpy")))))))
(packages->manifest (list my-package-with-my-foobar))
On Sat, 23 Oct 2021 at 11:04, Phil <phil@beadling.co.uk> wrote:
> Hi,
>
> Ludovic Courtès writes:
>
> > For historical reasons, ‘--with-source’ only applies to leaf packages,
> > unlike most (all?) other transformation inputs. Concretely, this works:
>
> Yes I think this is what I'm hitting. I want to reference a package
> using --with-source, but then immediately build an environment which
> feeds this source as an input into a 2nd package - forcing it to
> rebuild.
>
> My hack works but for propagated dependencies in python - but it's not a
> proper solution, and is brittle. I was going to try to improve
> it by writing a Guile script to avoid the overwriting - I can post any
> solution I find if I get something working.
>
> Currently I can only do 2 things at the command line it seems:
>
> 1. I can try package X without writing a package but only in isolation
> or as a leaf.
>
> 2. I can replace package X as a dependency of package Y, if I write a
> package
> for it.
>
> Being able to combine 1 and 2 at the command line - would be very
> useful.
>
> Cheers,
> Phil.
>
[-- Attachment #2: Type: text/html, Size: 4617 bytes --]
next prev parent reply other threads:[~2021-10-24 12:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 9:18 --with-source version not honored? Phil Beadling
2021-10-20 11:08 ` Julien Lepiller
2021-10-20 11:48 ` zimoun
2021-10-20 19:46 ` Phil
2021-10-21 10:18 ` zimoun
2021-10-21 20:22 ` Ludovic Courtès
2021-10-21 21:17 ` zimoun
2021-10-23 10:04 ` Phil
2021-10-24 12:11 ` Phil Beadling [this message]
2021-10-29 14:02 ` Ludovic Courtès
2021-10-20 19:25 ` Phil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOvsyQscDyBjqZrD7uzCrOYsaVh+GL1CCD35Qubwg_W8jKvejQ@mail.gmail.com \
--to=phil@beadling.co.uk \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).