From: iskarian@mgsn.dev
To: "Liliana Marie Prikler" <liliana.prikler@gmail.com>,
"Maxim Cournoyer" <maxim.cournoyer@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Rethinking propagated inputs?
Date: Wed, 08 Sep 2021 08:24:06 +0000 [thread overview]
Message-ID: <bf2951a2b67aa49fbfb72f97ff26df96@mgsn.dev> (raw)
In-Reply-To: <fa5cc690b904029fe2d1708a87bcd04de22e4947.camel@gmail.com>
Hi,
September 8, 2021 12:18 AM, "Liliana Marie Prikler" <liliana.prikler@gmail.com> wrote:
> Hi,
>
> Am Dienstag, den 07.09.2021, 12:01 -0700 schrieb Sarah Morgensen:
>
>> [...]
>>
>> However, IMO it doesn't make sense to automatically install these in
>> a profile when installing that package. If you're installing a
>> source-only package, you likely don't want all the transitive
>> dependencies automatically installed--what if you're just inspecting
>> the source, or want to try building it with different
>> dependencies? If you want all the build dependencies as well, you
>> would just do
>>
>> guix environment go-foo --ad-hoc go-foo
>>
>> like you would do for other Guix packages.
>
> I think if you wanted to build go-foo locally, you should go with just
> `guix environment go-foo' anyway. For the source code, you might be
> interested in `guix build --source'.
guix build --source doesn't capture any modifications made in the dependency package, such as
rewriting paths or other patching.
You're right, though, in that (for now) it's a rare use-case, and probably doesn't warrant the
added complexity and the extra field. It just feels... messy as it is now.
>> In the context of this discussion, I can think of three types of
>> solution:
>>
>> 1. Add a modifier like #:profile? (defaulting to #f) to
>> propagated-inputs entries
>> (propagated-inputs
>> `(("foo" #:profile? #t)))
>
> This is basically a weaker linked-inputs, because linked-inputs could
> be sanitized while these propagated inputs could not.
Good point. I included it because there seemed to be pushback on adding a field.
>> 2. Rename "propagated-inputs" to e.g. "profile-propagated-inputs",
>> and then introduce a new "propagated-inputs", which only propagates
>> into the inputs of dependents, and not into built profiles.
>
> Again same as introducing a new field, but also changing semantics for
> everything in the tree. I think having "propagated-inputs" mean what
> it means is fine. If we do find that we're lacking a field with
> certain semantics, we should add that or change existing fields in
> backwards-compatible ways.
I agree; I should have stated this differently ("Add a new field"). The name is just bikeshedding.
>> 3. Introduce a way to prevent an input from propagating anything into
>> the current package/profile
>> (inputs
>> `(("foo" #:propagate? #f)))
>> and then provide CLI options (transformations) to control this.
>
> Your example should have propagated-inputs. I'm not sure what benefit
> there is to this solution that isn't given by adding a field, except
> that it can't be sanitized. Now that I think about it, this seems to
> be a different syntax to 1.
Ah, I forgot to state that in this example, "foo" is the package with a propagated-inputs field,
and this is a dependent package (or a profile) which does not want "foo"'s propagated-inputs to be
propagated to it.
This way a packager has an "escape hatch" if something unwanted got propagated. Thinking about it
some more, though, in such a case it's more likely to want to disallow a specific package than a
whole set of propagated inputs. If such a feature would actually be useful (questionable), it's
probably better implemented differently than this (disallowed-inputs, perhaps, to mirror
disallowed-references)?
I hope I made some more sense this time!
--
Sarah
next prev parent reply other threads:[~2021-09-08 8:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-04 18:24 Rethinking propagated inputs? Liliana Marie Prikler
2021-09-05 0:50 ` Sarah Morgensen
2021-09-05 7:36 ` Liliana Marie Prikler
2021-09-05 9:50 ` Bengt Richter
2021-09-05 10:50 ` Guix Jargon File (WAS: Rethinking propagated inputs?) Liliana Marie Prikler
2021-09-05 14:54 ` Bengt Richter
2021-09-05 15:28 ` Liliana Marie Prikler
2021-09-05 15:53 ` Jonathan McHugh
2021-09-06 4:07 ` Bengt Richter
2021-09-05 10:06 ` Rethinking propagated inputs? Attila Lendvai
2021-09-05 10:56 ` Julien Lepiller
2021-09-05 16:17 ` Maxime Devos
2021-09-05 16:50 ` Liliana Marie Prikler
2021-09-05 19:18 ` Maxime Devos
2021-09-05 19:37 ` Liliana Marie Prikler
2021-09-05 20:27 ` Maxime Devos
2021-09-05 21:10 ` Liliana Marie Prikler
2021-09-07 11:49 ` Maxime Devos
2021-09-07 12:22 ` 宋文武
2021-09-06 18:07 ` Maxim Cournoyer
2021-09-06 18:45 ` Liliana Marie Prikler
2021-09-07 19:01 ` Sarah Morgensen
2021-09-08 7:18 ` Liliana Marie Prikler
2021-09-08 8:24 ` iskarian [this message]
2021-09-08 22:12 ` Ludovic Courtès
2021-09-08 22:34 ` zimoun
2021-09-08 22:55 ` Liliana Marie Prikler
2021-09-09 9:48 ` Ludovic Courtès
2021-09-16 18:01 ` Hartmut Goebel
2021-09-06 7:32 ` zimoun
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=bf2951a2b67aa49fbfb72f97ff26df96@mgsn.dev \
--to=iskarian@mgsn.dev \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
--cc=maxim.cournoyer@gmail.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).