Re: Problem with `direnv` package definition

[Tanguy Le Carrour]

Le 04/21, Christopher Baines a écrit :
> Tanguy Le Carrour <address@hidden> writes:
> > Le 04/20, Christopher Baines a écrit :
> >> Tanguy Le Carrour <address@hidden> writes:
> >> > However, in the package definition [2], 3 Go packages are listed as
> >> > "inputs" whereas they should be listed as "native-inputs". Is this
> >> > correct?
> >> That sounds right to me, although there have been issues with binaries
> >> generated with Go […]
> […]
> So, in contrast to some other package management systems, the runtime
> dependencies, or references of the output(s) in the case of Guix are not
> explicitly set in the package definition.
> 
> This is still something I have a little difficulty understanding, but
> the inputs/native-inputs distinction is more about architecture than
> runtime references.

Ouch?! If you have difficulty understanding it, imagine for me! ^_^'


> I've just pushed a commit that pulls in the relevant phase, and makes
> the inputs, native-inputs [1]. With that change, the size of the package
> does drop [2].

Thank you so much for that!


> That's not to say that making the inputs, native-inputs in this case is
> wrong, quite the opposite. […] Currently the direnv package is using the
> gnu-build-system, as it's one of the older go packages in Guix, however
> it does now pull in some phases from the go-build-system.
> […]
> Anyway, while the size of direnv should now be improved, there's still
> more improvements to be made to the direnv package if you're interested!
> I think it would be better to switch to using the go build system, and
> the package in Guix is quite a few versions behind.

So this might be something I could be investigating in a near future!
But I guess I'll have to read some Go package definitions first…
Which won't be a waste of time, for `fzf` is also written in Go!


Regards


-- 
Tanguy