Why import a package while several lines script are or so equally effective?

Questions
1

Sorry in advance for manners and customs, I DO NOT know for sure the reasons there.

If could fix issue or add feature within several lines script, why u still prefer importing a package?

You could see many such examples in forum, one most recent is post#8565

The top 2 reasons why I prefer scripting are:

  • exercise my typst knowledge
  • packages may bother each other
2
  • Well established solution that doesn’t require any effort/knowledge to implement/easier to remember.
  • Ideally a package is maintained, and any further issues are fixed for you.
  • API is usually much cleaner (but can be opinionated and not ideal).
  • Usually provides a more general/proper/robust solution that’s applicable to more use cases.

Though, having read quite a few packages…I can tell that the (vast?) majority are made by beginners or so, which results in not so elegant/efficient and error-prone solutions. But depending on the complexity, even the most robust and thought-through packages can have bugs, no matter the skill level.

You can just straight up copy the package implementation and use it, or strip it down to your specific use case. You have to decide what are your priorities and choose a solution accordingly.

3 Likes
3

Would many pkgs run together smoothly? Rough example:

#import "@preview/image-layout-package"
#import "@preview/figure-layout-package"
#import "@preview/content-theme-template-A"
#import "@preview/content-theme-template-B"
#import "@preview/image-theme-template"

Images are a subset of figure, figures are a subset of content. There are package and template both for images…

  • So, would those five imports run together smoothly in a single file.typ?
  • Or, how to assert the compiled file.pdf is fine if there are many imports?
4

It’s a bit abstract since it’s only an example, so the answer will be vague as well.

Packages should follow Typst best practices to preserve composability. A simple example of such guidelines would be: use and respect the page.numbering setting (instead of applying a hard-coded numbering pattern). In general, use typst show/set rules and built-in settings where it’s possible.

A lot of Typst’s core design is catered towards composability to enable packages to work well together. The more packages and documents use the established and built-in ways to configure and style a document, the more this is preserved.

And a more quirky answer to your question is: Your example only #imports these packages, and you have not applied any function or template from these packages. Because of this, the packages have no effect, and they cannot cause any problems for each other! Just importing does nothing.

Make sure it compiles without errors and without warnings. But you’ll also have to inspect the whole output document yourself, to know if the result is as you intended.

3 Likes
5

Incorrect. It does increase compilation time, which is why for heavy packages it’s not enough to comment a function call, you also need to comment the package import for some extra performance boost. I noticed it a lot with a few packages that were used in the paper (like grayness and pintorita imports alone add 4 s). But visually it does nothing, and for the vast majority of simple non-Wasm(?) packages the added package code evaluation adds negligible amount of time to the compilation process.

They would, but maybe they wouldn’t. Must specify concrete use case. For performance, you’ll have to profile the project.

1 Like
6

Heh, interesting but that’s a side effect and not relevant for the document output. If it was relevant, I’m all ears.

1 Like
7

But where is typst best practise (for package (for composability)) ?

  • api:
  • doc:

The only two best practises I can find on the Internet are api and doc…
A more bad thing is my network and git/gh tools can’t view or download github gists…

8

The gh gist command has existed for a long time now. Network issues would be a separate thing. If you can access the web page, then you can copy each file individually or download the gist as a Zip archive.

1 Like
9

It’s not a temporary network issue, it is everlasting. The zip link doesn’t download anything but retry again and again.

BTW, are there some “comprehensive” typst best practice public online? Perhaps I don’t get the key idea here?

/* because my  major is not software programming, 
I know the word "best practice", 
while never ever read some best practise of
sh, py, cpp, md, git, typ... */
10

Problem with Internet provider/firewall/etc.

Maybe a couple, but I haven’t read any, so can’t recommend. In the near future the documentation will be updated and hopefully will finally include best practices, because some of it was written like 4 years ago.

By the way, you start to ask unrelated questions. The topic should be around only the OP question, and some supplementary clarifying ones about a given solution.

1 Like
11

I’m not sure there is any good reference for this at all. For now, it’s a “developing community consensus”, and it will also evolve as Typst gets new features. Previously we’ve seen some interesting blog posts and talks on the topic of composable and maintainable templates, and I think more are needed…

1 Like
12

Thank you two for detailed answers, time to sum up:

  • why not scripting: #2 by Andrew
  • is pkgs composable: #4 by bluss
  • where best practise: the documentation and “developing community consensus”