unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Sarah Morgensen <iskarian@mgsn.dev>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: guix-devel@gnu.org, liliana.prikler@gmail.com
Subject: Re: Rethinking propagated inputs?
Date: Tue, 07 Sep 2021 12:01:30 -0700	[thread overview]
Message-ID: <8635qgi511.fsf@mgsn.dev> (raw)
In-Reply-To: <87lf49a886.fsf@gmail.com> (message from Maxim Cournoyer on Mon, 06 Sep 2021 14:07:21 -0400)

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> It seems the original issue pointed at was somewhat misguided; is there
> still something to be fixed about propagated inputs?  It seems the
> discussion has moved toward handling propagated inputs for the use of
> pkg-config.
>
> What are the current problems with it, and what would the advantages be
> to move away from the status quo?  If there aren't clear benefits, I'd
> prefer the status quo, abstaining from the added complexity.

As I mentioned up-thread:

Sarah Morgensen <iskarian@mgsn.dev> writes:

>> Does anyone have an idea how we should handle propagations for the sake
>> of pkg-config?  Perhaps we could add "linked-inputs", which are added
>> when building packages and environments when not using --ad-hoc, but
>> not when union-building profiles.  WDYT?
>
> I know nothing about pkg-config, but such an input would help
> simplify things for Go (and I think for Rust) since many inputs need to
> be propagated only at build-time.

In Go(/Rust), the dependency packages' output contains only source, and
for a package to build it must have the source of all its transitive
inputs available.

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.

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

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.

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.

I think the first two are clear and make the packager consider exactly
what they're going to propagate into user profiles.  Of course, both
also rely on the packager always knowing what should be propagated to a
user's profile or not.  The third option allows more control over that
(and could be combined with one of the first two), but feels a bit rough
to use...

WDYT?

--
Sarah


  parent reply	other threads:[~2021-09-07 19:02 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 [this message]
2021-09-08  7:18         ` Liliana Marie Prikler
2021-09-08  8:24         ` iskarian
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=8635qgi511.fsf@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).