Question: Can this be used for packages with foreign `#import`s?

[har7an]

Hello,

today I wanted to apply the package-check linter to one of my new projects. Based on some findings there actually I wanted to post an entirely different issue, but while assembling a few CLI invocations to demonstrate my issue I noticed nothing worked and I ended up with even more questions. I think I'm doing something wrong, so let me show you what I see.

The problem

Fundamentally, it appears I cannot use this linter to check standalone packages that #import other packages. Here's an example if you want to follow along:

git clone --revision 23b9b3350db04e6741cd0fa171c4df3f200ad728 https://gitlab.com/hartang/typst/cloudy
# You never know what symlinks might do to your paths...
cloudy="$(realpath "$PWD/cloudy")"
podman run --rm -it --security-opt label=disable --log-driver none -v "$cloudy:/data" ghcr.io/typst/package-check:0.4.0 check

And we see the following error:

error[compile/error]: The following error was reported by the Typst compiler: package not found (searched for @preview/testyfy:0.2.0)
  ┌─ src/clouds.typ:5:8
  │
5 │ #import "@preview/testyfy:0.2.0"
  │

I can see the package in typst universe and I know for a fact it's in the packages repository.

The question(s)

• Am I missing something?
• Is this kind of usage currently supported at all?
• Why does the bundled typst in this case (apparently) not download the missing dependencies?

Thank you in advance!

[elegaanz]

Loading packages is not handled by the Typst library directly, each application is free to implement it as it wants. In our case, I first wanted to implement that but IIRC there were some issues with Typst requiring a synchronous loading mechanism, while our HTTP client was asynchronous. There is probably a way to get it to work, I just didn't want to spend too much time on it. The result is that you either have to have all the required packages present in cache, or run the check command on the whole package repository (which will then be used as a source for foreign packages).

As for your other issue, I would accept a PR that adds the possibility to download packages if they are not present in the cache. Otherwise I can implement it myself, but I can't give any guarantee on when I will have time to do so, as this is not a very high priority issue.