unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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 --]

  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).