Streamlining local package configuration

General
1

Hey community, I just published my first typst package and had to endure the local package configuration process. On Ubuntu, I had to create the typst/packages/preview/tonguetoquill-usaf-memo/ folder under ~/.local/shares then create a symlink called 0.0.1 to my local repo clone. Because I installed Typst with Snap, I also had to add export XDG_DATA_HOME=~/.local/shares to my ~/.bashrc file. All this to import a package locally.

To anyone who’s experienced this awkward process: have you found an elegant workaround? My users need to install packages locally, and I don’t want to maintain a separate codebase or hacky code for local packages. If local package configuration sucks this much for me, asking my users to do this is a nonstarter.

I made a feature request issue on GitHub, but I want to get perspectives on local package configuration from the community in case I jumped the gun.

1 Like
2

There are a few current and upcoming ways to improve the situation.

  • if your package is made with typst-package-template, it includes a command just install-preview that will install the package in the right location (this requires the just command runner, and the script implementing this may require Linux – I plan to migrate the scripts to one of the tools below)
  • if you plan to have many packages that users need installed locally (e.g. because you don’t plan to release them on Universe), then Maintaining a private package namespace as a git repo may be interesting to you. (this requires your users to be somewhat technical as they need to manage a git repo, and is also bash-based)
  • using typship, you can typship download -n preview <package-repo> to install a package locally from a git repo
  • utpm is another, well, unofficial Typst package manager, that has relevant commands in its dev branch which should be merged fairly soon: utpm pkg install -n preview <package-repo> like above; utpm prj link --no-copy preview symlinks a local project (the --no-copy option will probably become the default)

All that said, I personally think your proposed --local-package option is not the solution. I don’t think it scales well to packages with dependencies on their own (imagine you had to specify five --local-package options due to transitive dependencies). Your goal is for your users to 1) not have to go through complicated installation steps and 2) not having to hack around a local (not installed) template; the solution is to make installation easier – see above for that.

“Snap doesn’t configure XDG_DATA_HOME” honestly sounds like a snap bug/limitation (it wouldn’t be the first one); that Typst follows the XDG base directory specification is a plus in my view, Snap should make it easier/the default to properly integrate into the system. I don’t know what other packaged versions of the Typst compiler there are, but for your Windows users, Scoop may be a nice solution. Looking at GitHub - typst-community/scoop-bucket: A scoop bucket for various unofficial typst tools., it seems that you can get your users set up with something similar to this (untested, mind you):

scoop bucket add main
scoop bucket add typst-community https://github.com/typst-community/scoop-bucket
scoop install main/typst
scoop install typst-community/typship
typship download -n preview https://github.com/SnpM/tonguetoquill-usaf-memo
2 Likes
3

Thanks for the info! typship comes pretty close to the functionality I’m looking for–although asking users to install an additional dependency is not ideal. Technically, I can just ship my own scripts to accomplish the configuration for various platforms for lower installation overhead. This seems like the route I have to take.

I still believe the ability to easily import a local package (without changing the template codebase) should be a part of the core typst compiler. I agree that multiple local package dependencies would be awkward with --local-package, but it would be much less awkward than setting it up manually or installing scoop+typship and running typship download -n preview https://repo.link five times.

--local-package would also be an override instead of default behavior, so it wouldn’t affect any of the other package installation methods except when users explicitly specify the flag.

Anyways, I appreciate the beautiful typesetting language, app, and ecosystem yall have created. Hoping to work more with this platform.

1 Like
4

Could you share a bit, please, why would you need users to install your package as a local package? Does your published repo require something you don’t want to publish to Typst Universe, or do you want users to be able to install pre-release version?

In the Github issue you say something about “intranet environment”, but I’m not sure I get it, could you share more information?

5

I think that a good solution for this would look something like a lock file and a tool that manages the sync (vs universe and custom sources, so that both are supported.)

1 Like
6

Great question. Convenient prerelease installation would be a huge plus on top of my primary requirements.

I can’t share a lot about my users’ network for security reasons. They likely can’t reach Typst Universe reliable.

7

I failed to address your point about transitive dependencies. --local-package <namespace:path> would be an inelegant solution for offline transitive dependency management.

The point of --local-package isn’t to replace the package manager though; it’s to link an individual package to local source code. This enables prerelease installs and supports my use case with much less overhead than the other solutions.

Plus, typship and utpm still make users install/link every transitive dependency. This is more related to the architecture of Typst package management as @bluss mentioned. Airgapped transitive dependency management will be a huge pain regardless of interface.

--local-package is the simplest solution for local source installation.