From: ludo@gnu.org (Ludovic Courtès)
To: sbaugh@catern.com
Cc: guix-devel@gnu.org
Subject: Re: Developing libraries for the GNU system with Guix
Date: Fri, 14 Oct 2016 15:01:30 +0200 [thread overview]
Message-ID: <87bmynaxud.fsf@gnu.org> (raw)
In-Reply-To: <87h98fkdjb.fsf@catern.com> (sbaugh@catern.com's message of "Thu, 13 Oct 2016 19:57:44 -0400")
Hello!
sbaugh@catern.com skribis:
> When I am hacking on some library Z, I continuously want to test the
> effects that my changes to Z have on packages A/B/C which depend on
> Z. The same applies, in general, when hacking on any package Z which
> other packages A/B/C depend on: While developing, I want to be able to
> rapidly mutate Z and see how this affects A/B/C.
A very common use case. Others have asked about it.
> I am not sure how to best achieve this. Here are some solutions:
>
> - When you change Z, rebuild A/B/C.
> This is much too slow at present.
Right, but note that it’s the only way to be confident that the change
in Z doesn’t break A/B/C. That said, I do understand that sometimes,
you want an “I know what I’m doing” (i.e., the ABI of Z hasn’t changed)
option to bypass that and test the run-time behavior of A/B/C.
For cases where you do want to rebuild anyway, I was thinking of making
the ‘--with-source’ option “recursive”, such that:
guix build --with-source=./guile-2.0.14rc1.tar.gz guile-json
would replace the source of Guile and build Guile-JSON against that.
> - Use grafts to update A/B/C through binary patching.
> This is also too slow, and AFAIK it can't really be sped up.
A/B/C have to be really big for this to be too slow! I think grafting
processes several MiB/s on my SSD laptop.
Again to make this more convenient, I thought we could have a
--with-graft option, which would work like --with-input except that it
would graft the new Z onto A/B/C instead of rebuilding them.
> - Use LD_LIBRARY_PATH to cause A/B/C to search for Z in a mutable place.
> This works for C libraries, but not generically; there are equivalent
> variables for some other languages but it's not a full solution.
Yeah, not great.
> - Before starting to hack on Z, build a new version of Z which includes
> a random hash and which A/B/C depend on; then bind-mount a mutable
> directory on top of that. (suggested by mark_weaver on IRC)
> This is the most palatable hack, but still a hack. The inclusion of a
> random hash prevents collision with other packages and the use of
> bind-mounting means we aren't actually mutating the store. This
> unfortunately also requires privileges: it's not usable by
> unprivileged users.
It is usable by unprivileged users when user namespaces are available.
Under these conditions, you could use ‘call-with-container’ and
bind-mount anything anywhere. Doesn’t sound too nice to me though.
> Here are some not currently available possibilities:
>
> - Create some kind of GUIX_LIBRARY_PATH in which packages are looked up
> first before looking at the compiled-in hash.
> This would be an attempt to make a generic equivalent of
> LD_LIBRARY_PATH. This could theoretically be implemented with variant
> symlinks, if they were available: https://lwn.net/Articles/680705/
At first sight this sounds very hacky, very much against the whole idea
of functional package management.
> - Currently every dependency is located at a well known globally unique
> and globally meaningful path; add some kind of "variant package"
> construct which specifies a package which is "passed in" to the
> environment (maybe by bind-mounting it in a filesystem namespace;
> implementation specifics aren't important). To put this in a
> programming language sense, one of these packages being present would
> turn a Guix distribution from a value into a function.
Not sure I understand. What do you mean by “passed in to the
environment”?
> - Massively speed up rebuilding A/B/C by performing incremental
> builds. Not sure how exactly this could work, it's just a thought.
No idea how this could work either.
Thanks for raising the issue!
Ludo’.
next prev parent reply other threads:[~2016-10-14 13:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 23:57 Developing libraries for the GNU system with Guix sbaugh
2016-10-14 13:01 ` Ludovic Courtès [this message]
2016-10-14 13:56 ` sbaugh
2016-10-14 18:58 ` Ricardo Wurmus
2016-10-17 22:04 ` Ludovic Courtès
2016-10-18 6:16 ` Ricardo Wurmus
2016-10-18 12:45 ` Ludovic Courtès
2016-10-23 14:12 ` sbaugh
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=87bmynaxud.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=sbaugh@catern.com \
/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).