Hi, September 8, 2021 12:18 AM, "Liliana Marie Prikler" <liliana.prik...@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