On 2023-09-04 21:59:47 -0500, Distopico 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. 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.
> 
> Many libraries in different languages don't follow semver, which can
> lead to cases like `rust-serde-json`, which, between versions "1.0.97"
> and "1.0.98," changed its dependency from `indexmap` "1.x" to "2.x,"
> causing several packages like rust-analyzer to break. I've also observed
> this in Haskell with packages like "text."
> 
> This is problematic because:
> 
>     - Over time, it becomes more vulnerable to libraries/packages
>       breaking.
> 
>     - It makes reproducible software more challenging, as "1.x" can
>       encompass many versions.
> 
>     - Debugging becomes difficult since that package could be a deep
>       dependency in the system package dependency chain, such as
>       Rust/Haskell/NPM, etc.
> 
>     - It makes it more likely that if a dependency changes, many
>       packages will need to be updated/rebuilt due to that change.
> 
> 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`.
> 
> This brings the following benefits:
> 
>     - Fewer packages will be prone to rebuilding when changing the
>       definition of a library.
> 
>     - Reduced likelihood of libraries/packages breaking.
> 
>     - Easier maintenance of packages and libraries without fear of
>       breaking others or having to update many.
> 
> There could be some potential disadvantages:
> 
>     - The list of library versions may grow larger, making it harder to
>       detect orphaned or unused versions.

I was recently thinking about this, and I think this should be solvable by
introducing a boolean flag (auto-dependency?) to the package definition stating
whether the package was added intentionally, or just as an auto-imported
dependency.  The importer (when running as -r) would set it to #t for all except
the top-level package.

After that we could have a clean up script that would delete all packages that
have this flag set to #t and are not referenced from any packages that have the
flag set to #f.  That should ensure that the list of packages does get cleaned
up eventually.

> 
> Additionally, I believe that a command to list the dependency tree of a
> package would be ideal for easier debugging.
> 
> Regards!

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.