Re: Shebang and python packages

[Reza Housseini]

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