GNU bug report logs -
#76513
[PATCH rust-team 00/77] Add module (gnu packages typst) and packages
Previous Next
Full log
View this message in rfc822 format
Hi Andrew,
On Sun Mar 2, 2025 at 2:39 AM -03, Andrew Wong via Guix-patches via wrote:
> Hi All,
>
> I've been working on implementing Alexis' changes and suggestions.
> However, I've run into a roadblock regarding the bug you mentioned in
> version 0.13.0. Though the bug has been fixed a few days ago, trying to
> build typst from the fixing commit has led me to a few roadblocks,
> because the git-packaged version of Typst depends on downloading
> git-packaged versions of its component packages, which I then tried to
> package themselves but ran up against more roadblocks. Has anyone here
> successfully packaged rust packages with github dependencies? Any
> notes/pointers/examples? I tried grepping around guix but couldn't find
> a good example.
You can try:
------
(snippet
#~(begin (use-modules (guix build utils))
(substitute* "Cargo.toml"
(("typst-dev-assets = \\{ git =.+")
"typst-dev-assets = \"0.13.0\"\n"))))
------
Along with:
------
(arguments '(#:install-source? #f))
------
It should solve the immediate problem, but might create others, depends on how
the rust program does the workspacing, e.g. you might get errors like this:
------
error: manifest path `/path/to/source/Cargo.toml` is a virtual manifest, but
this command requires running against an actual package in this workspace
------
> So far, I've just been trying to build the release version as retrieved
> from git, because it only has one git dependency
> 'rust-typst-dev-assets', but I can't get even that to build, so I am
> stumped.
Building the package directly from git (with git as a source) is different than
using crate-uri as a source. Reason being crates.io (or cargo in the broader
instance) does something called 'normalization' to its workspace packages, and,
as a consequence, dependencies, before shipping them as a '.crate' file. The
crates.io registry might not even ship 'typst-dev-assets' in this case, since
its a dev dependency (this is why it builds fine when using crate-uri instead
of git-reference).
What this means in practice, without diving into cargo-build-system too deep, is
it converts a 'virtual manifest' to actual packages that can be worked on using
subsequent cargo subcommands (like 'cargo package').
AFAIK (and I'd be really happy to be proved wrong here!), theres no easy way
to do this normalization without internet access, or without lock files (which
currently gets deleted by the cargo-build-system).
I wish I could give you any reference links to read or prove my statements,
however this is all from my own experience packaging rust, and many failed
attempts on even harder packages.
Back to your original problem, I think these steps would do the trick:
1. Remove the hard-dependency on git with the above substitute* snippet;
2. #:install-source? #f as the package argument;
3. Replace the 'install phase with your own that installs the files.
Not that you have to do it (see the "option 'c'" below), but just giving you one
(of many) ways to solve this specific problem if you/anyone reading this finds
it useful (specially for packaging crates that are not in crates.io).
> Is it OK if I just send in the next version of the patch series
> (with the search path fixes) and either a) allow someone with the skills
> to implement the fix after the patches are merged or b) wait (or ask)
> for the typst developers to release a "0.13.1" with the fix?
I don't know the proper guix procedure for this case, sorry.
However I can suggest applying the specific commit [1] from the fix PR [2] as a
guix patch - could be an option "c" :)
Best regards,
Murilo
[1] https://github.com/typst/typst/commit/acd3a5b7a5999d22fbf2da488744d564b2f3638e
[2] https://github.com/typst/typst/pull/5905
This bug report was last modified 20 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.