Hello Daniel,
On 2025-07-10 07:43, Daniel Littlewood wrote:
Hi guix-devel,
I have been working recently on packaging Ruby gems. There is a
particular
feature I have been unable to replicate, namely that gems declare their
dependencies with both a symbolic name and a version range. For
example,
sinatra 4.1.1 depends on logger >= 1.6.0. Gems also declare which
version of
Ruby they depend on, which I think can be an arbitrary version (not
just "is
it 2 or 3").
My understanding is that guix deals with this the same way other
distribution
package managers do, by hacking the symbolic mechanism to work: a human
identifies a "best possible" list of versions that build everything
people
seem to care about, and the whole system rolls forward together. This
is
appealing from a testing perspective, because there are less possible
configurations an installed system can be in.
However, I think this is unnecessarily limiting. It means that while
guix can
in principle be used to replace distribution package managers, it could
never
be used to replace something like bundler. That's unfortunate, because
language package managers like bundler are themselves limited in that
they
generally do not package system dependencies, meaning the dependency
tree is
not complete & you have to rely on multiple package managers. I don't
think
the "symbolic" mechanism can be made to work for this problem in
general,
because the space of requirements is really large.
The approach I have been working with in my projects is to write a
symbolic package for every single version, and pin the entire
dependency tree
with a manifest.scm file. This does work, but a) requires the use of an
external dependency resolution tool in order to compute the versions,
and b)
means that the package definitions are not complete in isolation. This
means
that if I give an incorrect version list (which is easy to do,
especially if
you depend on both ruby gems and system libs) guix will not build a
working
system.
I have been building towards doing this using logic-programming - using
Scryer Prolog.
Treating it all as a giant graph should provide some starting points,
though understandably the ranges presented in these package definition
files may not represent a true/actionable functional reality.
I am writing to ask whether something like this has been considered
previously, and especially whether it is known to be a dead end. I
don't know
whether the nix people have tried something similar, everything I could
find
seems to be about generating lockfiles/manifests.
I do not know this to be a dead end.
For my needs (packaging Rust in order to build Scryer Prolog), Ive
wanted to resolve some of the pre graph sides,
and have been resolving technical debt at my end.
I am not sure when I shall be poking this stack yet, as my focus is on a
lot of domains atm.
Hopefully I shall have something in place for Autumn.
Dan Littlewood
Kind regards,
Jonathan
