On Sun, Feb 23, 2025 at 04:48:10PM +0100, Ludovic Courtès wrote: > Hi, > > Efraim Flashner <efr...@flashner.co.il> skribis: > > > I would like to get away from the cargo-inputs and > > cargo-development-inputs if possible and to have all the packages as > > regular and native inputs. > > This is what I looked at in <https://issues.guix.gnu.org/53127>, but now > I realize this may be misguided: there are no packages to build, apart > from leaves. > > My inclination now would instead be to have “flat” packages with all the > origins of all their transitive dependencies as input, built straight > from info in ‘Cargo.lock’ (as Murilo suggests, I believe). > > We could arrange to maintain a list of origins (not packages) in > rust*.scm for all the libraries—anything that’s not a leaf—so we still > have a view of code that is shared by several leaf packages.
Current data:
(ins)efraim@3900XT ~/workspace/guix$ grep -c define-public
gnu/packages/crates*scm | sort --key 2 --numeric --field-separator : --reverse
gnu/packages/crates-io.scm:3871
gnu/packages/crates-vcs.scm:268
gnu/packages/crates-graphics.scm:262
gnu/packages/crates-web.scm:261
gnu/packages/crates-crypto.scm:237
gnu/packages/crates-gtk.scm:189
gnu/packages/crates-windows.scm:170
gnu/packages/crates-apple.scm:86
gnu/packages/crates-tls.scm:80
gnu/packages/crates-compression.scm:77
gnu/packages/crates-audio.scm:59
gnu/packages/crates-database.scm:55
gnu/packages/crates-shell.scm:34
gnu/packages/crates-check.scm:30
(cmd)efraim@3900XT ~/workspace/guix$ grep -c define-public
gnu/packages/crates*scm | awk -F : '{count += $2} END {print count}'
5679
About using a common list of origins:
It sounds like a good idea. However, it means that we still wouldn't be
able to update packages at times if they share a common dependency with
librsvg or a handful of other packages.
(ins)efraim@3900XT /tmp$ grep -c checksum librsvg-2.58.5/Cargo.lock
280
If we have 5 different versions of rust-rand-0.8 in one file then that
file grows to be very big very quickly. If we deduplicate the versions
by forcing them to use their-version-or-higher then we run the risk of
losing unused packages inside that file as packages get updated and not
all dependencies get removed. If every package has its own file with
its own dependencies, if there are overlaps then it'll already be in the
store. When there is an upgrade it is easy to see what needs to be
added and what can be dropped from that one file.
Assuming the import script can handle minor differentiations between our
packaged versions (newer versions having newer inputs?) and Cargo.toml,
I would be in favor of keeping a curated handful of crates that could be
shared between builds, with the option of importing a newer version into
that package's file as needed. I'm thinking libc, serde, syn, rand; but
these packages would also need to be updated using the script.
(ins)efraim@3900XT /tmp$ grep -c checksum serde-1.0.216/Cargo.lock
5
(ins)efraim@3900XT /tmp$ grep -c checksum syn-2.0.90/Cargo.lock
182
(ins)efraim@3900XT /tmp$ grep -c checksum rand-0.8.5/Cargo.lock
18
Well that got away from me really quickly. And both serde and rand
depend on syn-2. So a source-only import could work, but I'm not really
convinced about how practical trying to keep some shared crates in a
generic crates-io module would actually be.
--
Efraim Flashner <efr...@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
