Re: Pinned versions should be a requirement.

[Distopico]

On 2023-09-07, Simon Tournier <zimon.toutoune@gmail.com> wrote:

> Hi,
>
> On Mon, 04 Sep 2023 at 21:59, Distopico <distopico@riseup.net> wrote:
>
>> In my experience using Guix and attempting to make contributions, I've
>> noticed that the vast majority of times when a library breaks, it's
>> because one of its dependencies changed version.
>
> That’s because contributor and/or reviewer are not running
>
>     guix refresh -l foobar
>
> for checking that all the dependants of foobar still build.  Well, there
> is no easy solution, although QA is helping.  Note that this points is
> not listed in the long list of Katherine,
>
>         Re: How can we decrease the cognitive overhead for contributors?
>         Katherine Cox-Buday <cox.katherine.e@gmail.com>
>         Wed, 30 Aug 2023 10:11:02 -0600
>         id:e47299e8-43f8-aac8-61ba-420daeb88bdd@gmail.com
>         https://yhetil.org/guix/e47299e8-43f8-aac8-61ba-420daeb88bdd@gmail.com
>         https://lists.gnu.org/archive/html/guix-devel/2023-08
>
>
>
>>                                                  For instance,
>> referencing something like `rust-my-lib-1`, where "1" refers to the
>> semver "1.x" of the package, e.g., "1.0.32", and `rust-foo` depends on
>> `rust-my-lib == 1.0.32`. However, in some other package got updated to
>> "1.0.34" so `rust-foo` will break. I've seen this happen a lot with
>> Haskell and Rust libraries.
>
> Well, from my point of view, the issue depends on the upstream package
> ecosystem.  Considering Haskell, we follow LTS, currently
>
>         ;; Latest LTS version compatible with current GHC.
>         (define %default-lts-version "20.5")
>
> from the module (guix import stackage).  And note the lint checker,
> “guix lint -l”:
>
>     - haskell-stackage: Ensure Haskell packages use Stackage LTS versions
>
>

In terms of haskell I notice an incompetence of versions so even GHC are
semver the required version was other and several packages are taking
"text" internal GHC type and no the required package, you can see that
in this patch https://issues.guix.gnu.org/64840

>> For these reasons, I believe that pinned versions should be a
>> requirement in libraries, always specifying the exact dependency, for
>> example, `rust-serde-json-1.0.98`.
>
> In the Subject: of the message, it reads pinned/fixed.  The difference
> is:
>
>   + 'pinned': version that rarely changes
>   + 'fixed': mainly the ones with security fixes used as grafts
>
> as discussed in [1].  Maybe you already know, it is just in case or for
> other potential readers. :-)
>
>
For this case I'm referring mostly to pinned versions as requirement but
for LTS packages fixed could good as well

>> Additionally, I believe that a command to list the dependency tree of a
>> package would be ideal for easier debugging.
>
> Do you mean “guix refresh -l”?
>
> --8<---------------cut here---------------start------------->8---
> $ guix refresh -l gmsh
> Building the following 3 packages would ensure 4 dependent packages are 
> rebuilt: openfoam-com@2212 python-pygmsh@7.1.17 openfoam-org@10.20230119
> $ guix build $(guix refresh -l gmsh | cut -d':' -f2)
>     … build all packages impacted by a change in the package gmsh …
> --8<---------------cut here---------------end--------------->8---
>

I'm referring to something more like `cargo tree --depth=N` or `cabal freeze` to
see all the dependencias like

--8<---------------cut here---------------start------------->8---
my_package v0.1.0 (/gnu/rust.scm)
└── rust-rand v0.7.3
    ├── rust-getrandom v0.1.14
    │   ├── rust-cfg-if v0.1.10
    │   └── rust-libc v0.2.68
    ├── rust-libc v0.2.68 (*)
    ├── rust-rand_chacha v0.2.2
    │   ├── rust-ppv-lite86 v0.2.6
    │   └── rust-rand-core v0.5.1
    │       └── rust-libc v0.1.14 (*) ---->> We can detect this!
    └── rust-rand-core v0.5.1 (*)
[native-inputs]
└── cc v1.0.50
--8<---------------cut here---------------end--------------->8---

signature.asc
Description: PGP signature