Don't add propagated-inputs for all outputs

  • Done
  • quality assurance status badge
Details
5 participants
  • Josselin Poiret
  • ???
  • Liliana Marie Prikler
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Submitted by
???
Severity
normal
?
?
??? wrote on 26 Aug 2023 13:36
(address . guix-patches@gnu.org)(address . guix-devel@gnu.org)
87ttsm828q.fsf@envs.net
Hello, we have a TODO for "extend `propagated-inputs` with support for
multiple outputs". I try to do it for a while, but unable to find a
clear way, since add a new syntax for specify output in
propagated-inputs require changes in too many places..

Think about the intention, what we want is to avoid unwanted
propagated-inputs for building a package or user profiles, and
propagated-inputs is mostly used for development packages which
requiring headers/libraries from its inputs. It seems I can hardcode
the choice here to the "dev" output (if a package have both "dev" and
"out", its "out" should considered be an application) or the "out"
output (a library/development package).


Then the change is straight:
From 98a8666a0cbf33e24efff615243b98144a92c950 Mon Sep 17 00:00:00 2001
Message-ID: <98a8666a0cbf33e24efff615243b98144a92c950.1693047369.git.iyzsong@member.fsf.org>
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzsong@member.fsf.org>
Date: Sat, 26 Aug 2023 18:27:09 +0800
Subject: [PATCH] packages: Don't propagate inputs for non-development package
outputs.

* guix/packages.scm (transitive-inputs): Only include propagated inputs from a
package for its "dev" output, or its "out" output if the package doesn't have
a "dev" one.
---
guix/packages.scm | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

Toggle diff (23 lines)
diff --git a/guix/packages.scm b/guix/packages.scm
index ba98bb0fb4..435d55de71 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -1143,7 +1143,13 @@ (define (transitive-inputs inputs)
(loop rest result propagated first? seen)
(loop rest
(cons input result)
- (cons (package-propagated-inputs package) propagated)
+ ;; Only add propagated inputs for PACKAGE:dev, or PACKAGE:out
+ ;; when PACKAGE doesn't have a "dev" output.
+ (if (if (member "dev" (package-outputs package))
+ (member "dev" outputs)
+ (or (null? outputs) (member "out" outputs)))
+ (cons (package-propagated-inputs package) propagated)
+ propagated)
first?
(vhash-consq package outputs seen))))
((input rest ...)

base-commit: eeb71d778f149834015858467fbeeb1276d96d1d
--
2.41.0
Not much benifits now, but i think it will helps when we have more
mulitple outputs packages. Also how about add a slimming team aiming to
reduce the closure size of packages and system, anyone interested?

Thanks. ?
I
I
iyzsong wrote on 26 Aug 2023 15:53
[PATCH] profiles: Don't propagate inputs for non-development packages.
(address . 65550@debbugs.gnu.org)(name . ???)(address . iyzsong@member.fsf.org)
1f7f85189b17ebddb6d0e26afd7c5fad88c997e9.1693057951.git.iyzsong@member.fsf.org
From: ??? <iyzsong@member.fsf.org>

* guix/profiles.scm (package->manifest-entry): Only include propagated inputs
from a package for its "dev" output, or its "out" output if the package
doesn't have a "dev" one.
---
guix/profiles.scm | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

Toggle diff (24 lines)
diff --git a/guix/profiles.scm b/guix/profiles.scm
index fea766879d..9ed81dec4d 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -390,7 +390,14 @@ (define* (package->manifest-entry package #:optional (output "out")
((label package output)
(package->manifest-entry package output
#:parent (delay entry))))
- (package-propagated-inputs package)))
+ ;; Only add propagated inputs for PACKAGE:dev, or
+ ;; PACKAGE:out when PACKAGE doesn't have a "dev"
+ ;; output.
+ (if (if (member "dev" (package-outputs package))
+ (equal? "dev" output)
+ (equal? "out" output))
+ (package-propagated-inputs package)
+ '())))
(entry (manifest-entry
(name (package-name package))
(version (package-version package))

base-commit: 98a8666a0cbf33e24efff615243b98144a92c950
--
2.41.0
L
L
Liliana Marie Prikler wrote on 26 Aug 2023 16:21
(name . ???)(address . iyzsong@member.fsf.org)
851f008ab9e989badb8bcb10f4b7eee5bc5616c0.camel@gmail.com
Am Samstag, dem 26.08.2023 um 21:53 +0800 schrieb iyzsong@envs.net:
Toggle quote (6 lines)
> From: ??? <iyzsong@member.fsf.org>
>
> * guix/profiles.scm (package->manifest-entry): Only include
> propagated inputs from a package for its "dev" output, or its "out"
> output if the package doesn't have a "dev" one.
> ---
I think this patch misses the most obvious use case of the out:lib
split. I also think that hardcoding this list is bound to fail.

Instead, we could for the time being solve this with yet another
package property.
'((propagate-inputs-from "lib")) ; but not out
'((propagate-inputs-from . ("lib"))) ; same meaning, different style
'((propagate-inputs-from "out" "lib")) ; but not doc
If the property is missing, we still propagate from all outputs, as is
currently done.

WDYT?
?
?
??? wrote on 27 Aug 2023 09:30
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87edjpaqo2.fsf@envs.net
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (10 lines)
> Am Samstag, dem 26.08.2023 um 21:53 +0800 schrieb iyzsong@envs.net:
>> From: ??? <iyzsong@member.fsf.org>
>>
>> * guix/profiles.scm (package->manifest-entry): Only include
>> propagated inputs from a package for its "dev" output, or its "out"
>> output if the package doesn't have a "dev" one.
>> ---
> I think this patch misses the most obvious use case of the out:lib
> split. I also think that hardcoding this list is bound to fail.

Ah, that's true. We currently put both headers and pkgconfig files in
the "lib" output, I think we should put those files into "dev" instead,
only leave shared libraries in "lib" (then we don't need propagated it
anymore).

And I did a test to find packages with "lib" and propagated-inputs:
Toggle snippet (17 lines)
(use-modules (gnu packages)
(guix packages)
(srfi srfi-1)
(ice-9 pretty-print))

(define x
(delete-duplicates
(fold-packages
(lambda (package result)
(if (and (member "lib" (package-outputs package))
(not (null? (package-propagated-inputs package))))
(cons (package-name package) result)
result))
'())))

(pretty-print x)
Only hwloc and apache-arrow, and 24 packages (uniqued by name) have
a "lib" output, seems doable.


Toggle quote (10 lines)
> Instead, we could for the time being solve this with yet another
> package property.
> '((propagate-inputs-from "lib")) ; but not out
> '((propagate-inputs-from . ("lib"))) ; same meaning, different style
> '((propagate-inputs-from "out" "lib")) ; but not doc
> If the property is missing, we still propagate from all outputs, as is
> currently done.
>
> WDYT?

Yes, a property is more flexible here, haven't think about it. Well I
wishful think if we always follow a good convention (put development
files in "dev" or "out"), then maybe we can saving some bytes in code?
I'd like to split more packages with multiple outputs with "dev" to see
how the convention works out. If not then we could take this 'property'
way.

Thanks!
J
J
Josselin Poiret wrote on 27 Aug 2023 09:34
Re: [bug#65550] [PATCH] profiles: Don't propagate inputs for non-development packages.
(name . ???)(address . iyzsong@member.fsf.org)
87edjp546r.fsf@jpoiret.xyz
Hi everyone,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (13 lines)
> I think this patch misses the most obvious use case of the out:lib
> split. I also think that hardcoding this list is bound to fail.
>
> Instead, we could for the time being solve this with yet another
> package property.
> '((propagate-inputs-from "lib")) ; but not out
> '((propagate-inputs-from . ("lib"))) ; same meaning, different style
> '((propagate-inputs-from "out" "lib")) ; but not doc
> If the property is missing, we still propagate from all outputs, as is
> currently done.
>
> WDYT?

I don't really like the hackiness of this (yet another weird thing for
independent contributors to learn), but I also understand the need.
This one LGTM, but maybe we should think a bit more about simpler
solutions before committing to this.

Best,
--
Josselin Poiret
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCgAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmTq/IwQHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5Fhcaigk4DACTjnep95n94z6NvwqpwE1qUnSppWFpcu4p
xD0jb5UVB+9voHTNCkLtkCYy5pdgi0Ua+pZgjS+aGEGZ/Cffmk4SsQhAzKD/r4/u
UTaidht6FAgP/SPTbDKZXfMa2iJnQkuNmtq89bpSOQD6rfyjLr+otPDOpoeEAqzq
LLI+Lzz/TK3J/3/fVAEAlPLztgPvKgFKa4+nFgOwKHSon8hDYDpC9id95fJt7Fcm
MIf0oTJtYXhYYtC5aQGRB3Ht5aqI7Ru414Hgm2L3pyJ8TVBM+inUE+kI2geTQru3
4oy7zc2t85xh/vS82VbirCdARBmURwQ0C3cHH6OF5mqyBQyLMoQ5n5YKGH6RSxvW
M/yEfLhnkj93Zcw50kXEeRTKE0NXk2VUFLxMiZLunXbB9vnh/YvKLiwzMFA8Qleb
5ognJnNFY5PlBBcNjCc/+fwDpHgxCZ9mS4Uuaz1f0xhc1mHGlOe2r6S133+oK0zs
GADdmOM90yY4a6+rLjW7hQOxLZosmYQ=
=SMWB
-----END PGP SIGNATURE-----

L
L
Liliana Marie Prikler wrote on 27 Aug 2023 11:31
Re: [PATCH] profiles: Don't propagate inputs for non-development packages.
(name . ???)(address . iyzsong@envs.net)
81f39ef4b6e0ec4de7b55446c755fb0dec621c49.camel@gmail.com
Am Sonntag, dem 27.08.2023 um 15:30 +0800 schrieb ???:
Toggle quote (17 lines)
> > Instead, we could for the time being solve this with yet another
> > package property.
> >   '((propagate-inputs-from "lib")) ; but not out
> >   '((propagate-inputs-from . ("lib"))) ; same meaning, different
> > style
> >   '((propagate-inputs-from "out" "lib")) ; but not doc
> > If the property is missing, we still propagate from all outputs, as
> > is currently done.
> >
> > WDYT?
>
> Yes, a property is more flexible here, haven't think about it.  Well
> I wishful think if we always follow a good convention (put
> development files in "dev" or "out"), then maybe we can saving some
> bytes in code? I'd like to split more packages with multiple outputs
> with "dev" to see how the convention works out.  If not then we could
> take this 'property' way.
I'd really like to avoid yet another special output, when "bin", "lib",
etc. have already been given clear meanings, one of which strongly
overlaps with "stuff that wants propagated inputs for pkg-config
reasons".

The only package that currently has a "dev" output is mariadb, and it's
quite an odd one, as "dev" has been introduced to reduce closure size,
not to propagate even more. I don't think that hardcoding output names
works given this precedent. At the very least, "dev" is the wrong
choice.

Cheers
?
?
??? wrote on 29 Aug 2023 12:24
Re: [bug#65550] [PATCH] profiles: Don't propagate inputs for non-development packages.
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
877cpedu3k.fsf@envs.net
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (5 lines)
> I'd really like to avoid yet another special output, when "bin", "lib",
> etc. have already been given clear meanings, one of which strongly
> overlaps with "stuff that wants propagated inputs for pkg-config
> reasons".

The benefit to put headers files and libraries files into seperated
outputs is to reduce the runtime closure size of packages, for example
my home profile contains xfce, emacs, fonts, etc. has total 5GiB (by
guix size), and they have 300MiB under include.

calculated by:
Toggle snippet (7 lines)
x=/gnu/store/0fyhci5kv03rfb9430jqs9wki2ifq5ja-profile
guix size $x
for i in `guix size $x`;
do [ -e $i/include ] && du -sb $i/include;
done | awk '{ sum += $1 } END { print sum / 1024 / 1024 }'

If put headers and other development files into a "dev" output, then
those 300MiB can be saved (won't need to be substituted if substitutes
available). Note that use a "include" output won't help here if you
leave pkg-config files in "lib", since pkg-config files need reference
its include and binaries need reference its libraries.

So it seems to me a "dev" output is unavoidable, also both Debian and
Alpine Linux use '-dev' packages for the same reason, it should be
familiar to learn..
L
L
Liliana Marie Prikler wrote on 29 Aug 2023 19:01
(name . ???)(address . iyzsong@envs.net)
d8ba1d6e34c74ce480f8fac9e047243b6f858ea1.camel@gmail.com
Am Dienstag, dem 29.08.2023 um 18:24 +0800 schrieb ???:
Toggle quote (30 lines)
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
> > I'd really like to avoid yet another special output, when "bin",
> > "lib", etc. have already been given clear meanings, one of which
> > strongly overlaps with "stuff that wants propagated inputs for pkg-
> > config reasons".
>
> The benefit to put headers files and libraries files into seperated
> outputs is to reduce the runtime closure size of packages, for
> example my home profile contains xfce, emacs, fonts, etc. has total
> 5GiB (by guix size), and they have 300MiB under include.
>
> calculated by:
> --8<---------------cut here---------------start------------->8---
> x=/gnu/store/0fyhci5kv03rfb9430jqs9wki2ifq5ja-profile
> guix size $x
> for i in `guix size $x`;
>   do [ -e $i/include ] && du -sb $i/include;
> done | awk '{ sum += $1 } END { print sum / 1024 / 1024 }'
> --8<---------------cut here---------------end--------------->8---
>
> If put headers and other development files into a "dev" output, then
> those 300MiB can be saved (won't need to be substituted if
> substitutes available).  Note that use a "include" output won't help
> here if you leave pkg-config files in "lib", since pkg-config files
> need reference its include and binaries need reference its libraries.
>
> So it seems to me a "dev" output is unavoidable, also both Debian and
> Alpine Linux use '-dev' packages for the same reason, it should be
> familiar to learn..
There is little point in a dev package when you blow up its size by
propagating inputs…
?
?
??? wrote on 30 Aug 2023 12:55
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87a5u8vlyf.fsf@envs.net
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (14 lines)
> Am Dienstag, dem 29.08.2023 um 18:24 +0800 schrieb ???:
>> [...]
>> If put headers and other development files into a "dev" output, then
>> those 300MiB can be saved (won't need to be substituted if
>> substitutes available).  Note that use a "include" output won't help
>> here if you leave pkg-config files in "lib", since pkg-config files
>> need reference its include and binaries need reference its libraries.
>>
>> So it seems to me a "dev" output is unavoidable, also both Debian and
>> Alpine Linux use '-dev' packages for the same reason, it should be
>> familiar to learn..
> There is little point in a dev package when you blow up its size by
> propagating inputs…

Well propagated-inputs won't increase size of a package, they bring some
of its inputs when build other one to remove the need to list those some
inputs as inputs of the other one.

Consider gtk+ and mousepad:
gtk+ propagated cairo, freetype, pango, etc.
so I don't need add those inputs to mousepad, and if gtk+ doesn't
propagated them then I must add them to mousepad because those are
actually needed (because pkg-config check them and need link flags
from those dependencies of gtk+).

But for runtime, when substitute of mousepad is available, if we split
thoes packages with "dev" outputs, guix size mousepad would still be
something like:

...
/gnu/store/xxxx-mesa-23.1.4
/gnu/store/xxxx-freetype-2.13.0
/gnu/store/xxxx-gtk+-3.24.37
...

It won't include any "dev" output of its dependencies packages, since
development files are not referenced by mousepad's binary, so the size
of headers and development files is saved (won't be substituted).

Only when substitute of mousepad is not available, you'll start by download
mesa-23.1.4-dev, gtk+3.24.37-dev, etc. And after build, those "dev"
outputs can be GCed immediately.


Hope it's clear now!
M
M
Maxim Cournoyer wrote on 1 Sep 2023 04:16
Re: bug#65550: Don't add propagated-inputs for all outputs
(name . ???)(address . iyzsong@envs.net)
87msy67i4m.fsf_-_@gmail.com
Hi,

??? <iyzsong@envs.net> writes:

Toggle quote (30 lines)
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
>> I'd really like to avoid yet another special output, when "bin", "lib",
>> etc. have already been given clear meanings, one of which strongly
>> overlaps with "stuff that wants propagated inputs for pkg-config
>> reasons".
>
> The benefit to put headers files and libraries files into seperated
> outputs is to reduce the runtime closure size of packages, for example
> my home profile contains xfce, emacs, fonts, etc. has total 5GiB (by
> guix size), and they have 300MiB under include.
>
> calculated by:
>
> x=/gnu/store/0fyhci5kv03rfb9430jqs9wki2ifq5ja-profile
> guix size $x
> for i in `guix size $x`;
> do [ -e $i/include ] && du -sb $i/include;
> done | awk '{ sum += $1 } END { print sum / 1024 / 1024 }'
>
> If put headers and other development files into a "dev" output, then
> those 300MiB can be saved (won't need to be substituted if substitutes
> available). Note that use a "include" output won't help here if you
> leave pkg-config files in "lib", since pkg-config files need reference
> its include and binaries need reference its libraries.
>
> So it seems to me a "dev" output is unavoidable, also both Debian and
> Alpine Linux use '-dev' packages for the same reason, it should be
> familiar to learn..

I'm not convinced that saving 300 MiB on 5 GiB is worth making using
Guix packages more complicated, especially in this age of compressed
file systems (text files compress very well). We'd also have to change
a couple things to make it convenient and not have to plaster the code
base with ugly `(,lib "dev") inputs ^^'.

I reckon it could all be automated, but I'm not sure it's worth the
effort at this stage (there bigger low hanging fruits to pick in my
opinion -- such as moving static libraries automatically in the gnu
build system, paying more attention to large documentation or unecessary
installed files, etc.).

--
Thanks,
Maxim
M
M
Maxim Cournoyer wrote on 1 Sep 2023 04:34
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87a5u67hb7.fsf_-_@gmail.com
Hi Liliana and ???,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (18 lines)
> Am Samstag, dem 26.08.2023 um 21:53 +0800 schrieb iyzsong@envs.net:
>> From: ??? <iyzsong@member.fsf.org>
>>
>> * guix/profiles.scm (package->manifest-entry): Only include
>> propagated inputs from a package for its "dev" output, or its "out"
>> output if the package doesn't have a "dev" one.
>> ---
> I think this patch misses the most obvious use case of the out:lib
> split. I also think that hardcoding this list is bound to fail.
>
> Instead, we could for the time being solve this with yet another
> package property.
> '((propagate-inputs-from "lib")) ; but not out
> '((propagate-inputs-from . ("lib"))) ; same meaning, different style
> '((propagate-inputs-from "out" "lib")) ; but not doc
> If the property is missing, we still propagate from all outputs, as is
> currently done.

I'm rather against the proposed changes as it stands. I think it'd lead
to a lot of noise in the code base and favor more complex splits of
packages, which I'm doubtful is worth the cost (in terms of
hackiness/complexity).

Since I've known Guix, I've appreciated that a simple 'find $(guix build
some-package) typically shows me the package whole, except perhaps for
its doc and debug symbols. Having to know which packages have a "lib"
outputs when using them in package definitions is also not fun in my
experience (you start by adding the package, then it fails, then you
verify its outputs, then you add `(,package "lib")), and I fear going to
a "dev" output would bring the same kind of annoyance but at larger
scale.

I think we'd need to evaluate what we'd gain in terms of size reduction
a bit more carefully before moving in this direction and how it'd impact
the user experience. E.g., if we can reduce the minimal Guix image size
by maybe 30%, that'd be nice, but if we're talking of about 5% like in
your example profile, it doesn't seem worth the complexity to me.

--
Thanks,
Maxim
?
?
??? wrote on 1 Sep 2023 14:53
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87a5u6yrz0.fsf@envs.net
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (30 lines)
> Hi Liliana and ???,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
>> Am Samstag, dem 26.08.2023 um 21:53 +0800 schrieb iyzsong@envs.net:
>>> From: ??? <iyzsong@member.fsf.org>
>>>
>>> * guix/profiles.scm (package->manifest-entry): Only include
>>> propagated inputs from a package for its "dev" output, or its "out"
>>> output if the package doesn't have a "dev" one.
>>> ---
>> I think this patch misses the most obvious use case of the out:lib
>> split. I also think that hardcoding this list is bound to fail.
>>
>> Instead, we could for the time being solve this with yet another
>> package property.
>> '((propagate-inputs-from "lib")) ; but not out
>> '((propagate-inputs-from . ("lib"))) ; same meaning, different style
>> '((propagate-inputs-from "out" "lib")) ; but not doc
>> If the property is missing, we still propagate from all outputs, as is
>> currently done.
>
> [...]
>
> I think we'd need to evaluate what we'd gain in terms of size reduction
> a bit more carefully before moving in this direction and how it'd impact
> the user experience. E.g., if we can reduce the minimal Guix image size
> by maybe 30%, that'd be nice, but if we're talking of about 5% like in
> your example profile, it doesn't seem worth the complexity to me.

I agree, thanks Maxim and Liliana for the inputs!
M
M
Maxim Cournoyer wrote on 1 Sep 2023 17:03
(name . ???)(address . iyzsong@envs.net)
87ttse0wby.fsf@gmail.com
Hi,

??? <iyzsong@envs.net> writes:

[...]

Toggle quote (8 lines)
>> I think we'd need to evaluate what we'd gain in terms of size reduction
>> a bit more carefully before moving in this direction and how it'd impact
>> the user experience. E.g., if we can reduce the minimal Guix image size
>> by maybe 30%, that'd be nice, but if we're talking of about 5% like in
>> your example profile, it doesn't seem worth the complexity to me.
>
> I agree, thanks Maxim and Liliana for the inputs!

Should we close this issue for now?

--
Thanks,
Maxim
?
?
??? wrote on 2 Sep 2023 02:43
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
871qfhiewa.fsf@envs.net
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (16 lines)
> Hi,
>
> ??? <iyzsong@envs.net> writes:
>
> [...]
>
>>> I think we'd need to evaluate what we'd gain in terms of size reduction
>>> a bit more carefully before moving in this direction and how it'd impact
>>> the user experience. E.g., if we can reduce the minimal Guix image size
>>> by maybe 30%, that'd be nice, but if we're talking of about 5% like in
>>> your example profile, it doesn't seem worth the complexity to me.
>>
>> I agree, thanks Maxim and Liliana for the inputs!
>
> Should we close this issue for now?

Yes, closing.
Closed
L
L
Ludovic Courtès wrote on 9 Sep 2023 12:38
Re: [bug#65550] [PATCH] profiles: Don't propagate inputs for non-development packages.
(address . iyzsong@envs.net)
87o7ibzl6c.fsf@gnu.org
Hello!

iyzsong@envs.net skribis:

Toggle quote (6 lines)
> From: ??? <iyzsong@member.fsf.org>
>
> * guix/profiles.scm (package->manifest-entry): Only include propagated inputs
> from a package for its "dev" output, or its "out" output if the package
> doesn't have a "dev" one.

What’s the rationale?

Right now, there’s only one package with an output called “dev”:

Toggle snippet (4 lines)
$ guix package -A |cut -f3|grep dev|wc -l
1

So the focus on “dev” is debatable.

More importantly, this would break things like:

guix shell python python-scipy -C -- python3 -c 'import numpy'

… where ‘python-numpy’ is propagated by ‘python-scipy’.

Definitely not something we want to change.

WDYT?

Ludo’.
?
Your comment

This issue is archived.

To comment on this conversation send an email to 65550@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 65550
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch