all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Reza Housseini <reza.housseini@gmail.com>
To: "François J." <francois-oss@avalenn.eu>
Cc: help-guix@gnu.org
Subject: Re: Shebang and python packages
Date: Sun, 13 Jun 2021 11:16:57 +0200	[thread overview]
Message-ID: <CAGZc64HLJyeJS5DYriMunLygZirquSivw-Ad6zqwPT62bCRyLw@mail.gmail.com> (raw)
In-Reply-To: <20210610104519.tauqzervutn7hexy@noop.avalenn.eu>

On Thu, Jun 10, 2021 at 4:53 PM François J. <francois-oss@avalenn.eu> wrote:

> Hello,
>
> On Fri, Jun 04, 2021 at 12:50:03AM +0200, Tobias Geerinckx-Rice wrote:
> > Propagated-inputs are a hack that says as much as ‘when the user installs
> > package A, pretend like they also asked to install package B in the same
> > profile’.  That is *not* a good thing!  It's a work-around for broken
> > packages and packages that would be far too much work to package in a
> more
> > Guixy way.  Propagation causes all sorts of problems and makes profiles
> more
> > fragile.  Avoid it.
>
> Thank you for this explanation. I fighted a lot with the concept of
> propagated inputs and this descriptions makes a lot of sense to me.
>
> I am progressively thinking that propagated-input are used too much
> in Guix packages. Python packages seem concerned a lot by this but I
> have not used Guix enough to know if it is localized there or if it
> is generalized. At least it is a risk I am just identifying on the
> way Go packages are done (and makes me think about how we can evolve
> go-build-system to avoid this).
>
> I am not sure about what to do with that but reading this makes me feel
> less alone.
>
> François
>
>
As far as I understand it, are propagated-inputs in fact runtime
dependencies which boils down to shared libraries. The proper way to handle
these, is having them as inputs and tell the build target where they are to
be found in the store during runtime (e.g. -rpath). So the only thing which
is missing is a (guixy) way to hand over these gnu store paths of this
shared libraries to the build system. At the moment this has to be done for
each build system separately and it is not very consistent over all
packages.

This is my conclusion about propagated-inputs, please correct me if I'm
wrong.

Cheers Reza

      reply	other threads:[~2021-06-13 12:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 21:09 Shebang and python packages Phil
2021-06-03 21:24 ` Tobias Geerinckx-Rice
2021-06-03 21:36   ` Phil
2021-06-03 22:50     ` Tobias Geerinckx-Rice
2021-06-10 10:45       ` François J.
2021-06-13  9:16         ` Reza Housseini [this message]

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=CAGZc64HLJyeJS5DYriMunLygZirquSivw-Ad6zqwPT62bCRyLw@mail.gmail.com \
    --to=reza.housseini@gmail.com \
    --cc=francois-oss@avalenn.eu \
    --cc=help-guix@gnu.org \
    /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.