From: Katherine Cox-Buday <cox.katherine.e@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: 41790@debbugs.gnu.org
Subject: [bug#41790] [PATCH] Update emacs-direnv
Date: Wed, 10 Jun 2020 13:31:10 -0500 [thread overview]
Message-ID: <87lfkuzsb5.fsf@gmail.com> (raw)
In-Reply-To: <87zh9alrtz.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Wed, 10 Jun 2020 20:05:12 +0200")
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>
>> I disagree. If propagated inputs are not for this -- making the package
>> even functional -- what are they for?
>
> IIUC, they are to be used as a last resort, e.g., when the package
> cannot possibly build without them.
I checked the Guix manual for the intended use of propagated inputs
since I didn't completely understand how what is in the runtime
environment would affect the build environment. I found something which
maybe is open to interpretation:
"To ensure that libraries written in those languages can find library
code they depend on at run time, run-time dependencies must be listed
in propagated-inputs rather than inputs."
Maybe a binary required to operate is no different than "library code
they depend on at run time"?
> Reason is propagated inputs pollute user's profile. E.g., someone may
> want to use a different direnv, and this propagated input would
> conflict with their package.
That's another good point I hadn't considered: what if for some reason a
user wants a different version of the tool (presumably provided by Guix
as well)?
> I'll let maintainers decide about this, and hopefully clarify what can
> and cannot be propagated, at least in Emacs packages. This will be
> useful feedback for future reviews.
That's a good idea. I have an opinion, but it is not fully informed. I
appreciate the review, conversation, and appeal to authority!
> Meanwhile, you can still provide a patch only bumping emacs-direnv. It
> is also fine in you prefer to wait.
I'll let this one sit. The version bump was a side-effect of me
believing the package should also install the tool.
--
Katherine
next prev parent reply other threads:[~2020-06-10 18:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 15:12 [bug#41790] [PATCH] Update emacs-direnv Katherine Cox-Buday
2020-06-10 16:11 ` Nicolas Goaziou
2020-06-10 16:26 ` Katherine Cox-Buday
2020-06-10 18:05 ` Nicolas Goaziou
2020-06-10 18:31 ` Katherine Cox-Buday [this message]
2020-06-10 18:46 ` Oleg Pykhalov
2020-06-11 14:44 ` Katherine Cox-Buday
2020-06-11 20:03 ` Oleg Pykhalov
2020-06-11 20:31 ` Oleg Pykhalov
2021-08-06 4:49 ` bug#41790: " Maxim Cournoyer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfkuzsb5.fsf@gmail.com \
--to=cox.katherine.e@gmail.com \
--cc=41790@debbugs.gnu.org \
--cc=mail@nicolasgoaziou.fr \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.