all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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




  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.