Replace bash scripts by a tool for Typst package management such as typship or utpm

[SillyFreak]

The Justfile and CI actions of the template are currently powered by a few scripts in this package, located in scripts/. This duplicates code between all packages using this template, and makes using that functionality harder on non-linux machines.

It would thus be useful to evaluate external tools for replacing the scripts' responsibilities. These are currently

• locating the package install location for different platforms (scripts/setup:6-13)
• reading package metadata from typst.toml, particularly package name and version for crafting paths and filenames (scripts/setup:15-21)
• enumerating package files, respecting the .typstignore file (scripts/package:25-68)
• collecting and installing package files (scripts/package:70-86)
• uninstalling packages (scripts/uninstall:27-33)
• publishing a package by making a branch in preparation for a PR on typst/packages (.github/workflows/release.yml:57-71)
• misc related logic such as command line argument parsing and validating, and error handling

Not part of any scripts at the moment, but desirable:

• collecting the even smaller set of files that is required for installing a package (as opposed to publishing to Universe) by reading typst.toml's exclude
• creating proper Github releases and adding artifacts (zip files) to them
• ...?

---

I'd like to gather here thoughts on these and possible additional requirements from external package management tools, and use this as a starting point for evaluating typship and utpm.

[npikall]

@SillyFreak I would like to add some thoughts here. In my humble opinion, it would also be very useful, if a package manager had the following capabilities:

• bumping the package to a new version (editing the version numbers in the typst.toml, the README and all .typ files where imported)
• updating dependencies to latest (optionally non backwards compatible) versions.
• maybe also checking if the latest entry in the CHANGELOG is aligned with the latest version

I am not sure if there are tools around, which do that, but so far I haven't encountered them.
Currently I have written Python scripts, which handle that for me. They basically read all files and swap the old version with a new one. These scripts are still somewhat primitive, but they get done what I want them to do.
Here is one that updates the dependencies in typst files.
And here is another, that bumps the version of the package.

Additionally I think it would be great, if such a tool would be adapted in the template, that there may be a Developers guide in the README, which mentions all the tools that can/should be used in order to have a complete experience with the package-template.

[Thumuss]

It would be great if you can make an issue on utpm to propose these features. We are already looking for contributors but anything that can help peoples using this tool would be great <3

[SillyFreak]

I have looked at typship today, and my thoughts are the following:

• installing to the correct location in a specified namespace: yes, using typship install. However, the set of files is not entirely correct: Fix exclude/install walker logic regarding directories sjfhsjfh/typship#31
• symlink to the correct location: yes, using typship dev, but only to the preview namespace: dev for local packages sjfhsjfh/typship#30
• none of @npikall's suggestions (bumping package version, updating dependencies, checking CHANGELOG)
• publish to Universe: yes, using typship publish. This creates a branch on a specified fork of typst/packages, and does so better than the template since the branch will be based on the upstream main branch, not the fork's. It then creates a PR from that branch
  • however, this command is interactive: Skip interactive prompt using publish sjfhsjfh/typship#14
  • also, this requires a previous interactive typship login, which is also interactive. The access token can be put directly into a configuration file instead, but more directly (e.g. Allow passing the credentials by environment variables sjfhsjfh/typship#15) would be nice. I feel like not having to store the PAT in a file in CI could be beneficial when it comes to avoiding accidentially packing that up in a downloadable bundle.
  • also, the current approach of the template is to not actually open the PR (see Allow creating the submission PR to custom repo/branch sjfhsjfh/typship#7 (comment)), which I appreciate because it requires one final manual step before touching a repo not managed by the package author (but the PR being opened is a draft, so it's not that bad)
• just collecting non-excluded files, e.g. to add as an artifact to a Github release: no, see Enhance the experience of releasing and publishing sjfhsjfh/typship#12
• for private package authoring: installing packages from outside Universe via typship download. This is relevant for the template when you try to test a package that depends on another private package, since then you need to be able to install the dependency in CI.

So there are a few open points here, especially regarding non-interactive usage, but typship is actually pretty close to implementing everything the template needs.