Community

[ornate condor]

SillyFreak

[typst-community/guidelines] Pull request closed: #4 remove spurious context expressions in Don't example

SillyFreak

[typst-community/guidelines] Pull request opened: #5 correct concatenation in joining Don't example

The "Don't" example for content joining did not accumulate content in the res variable due to a missing assignment operator.

SillyFreak

[typst-community/guidelines] Pull request closed: #5 correct concatenation in joining Don't example

[prime robin]

@elfin sparrow whats your opinion on choosing a more permissive license

at the moment I am unable to use my own code constributed to valkyrie due too the strict licensing of the GPL

[elfin sparrow]

Yeah absolutely, truth be told I know nothing about licenses so if you can suggest one I'll go with that :p

[prime robin]

I generally default to MIT, this is frequently used in rust projects and allows for comercial usage

[elfin sparrow]

I'll finish my pizza and change the license

[prime robin]

lmao

have a good meal

[elfin sparrow]

Probably don't need to bump the version on typst universe?

[prime robin]

we can do that next release

add it to the milestone

and changelog

@elfin sparrow when you do please make a PR so i can give written permission, relicensing from something like GPL needs permission by all contributors i believe.

and having it written down makes it water tight i believe

[sullen pivot]

I worry that the relicensing of cetz to GPL might cause issues as well

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #9 Change license to MIT

License has been loosened from GPL-3.0-only to MIT.

[elfin sparrow]

The reason I originally went with GPL was the idea that people would be compelled to share any improvements they've made, I'm guessing it was probably a similar logic for cetz?

[ornate condor]

tingerrr

[typst-community/valkyrie] Pull request closed: #9 Change license to MIT

[elfin sparrow]

tinger, before I press go, can you sanity check? 😛 I'm notorious for turning one PR into 10

oo good

😛

[prime robin]

I did

[elfin sparrow]

thanks ^^

also slight sidetrack but let me know how you get on with the package and if you have any thoughts for improvements 🙂

[solid umbra]

wait wut

CeTZ changed to GPL?

this is a bit bad lol

this can cause ecosystem-wide problems

@smoky juniper can you comment on this?

nvm just noticed this is already being discussed on #discussions

carry on lol

[flat bane]

So I'm also by no means a licensing expert an this is not legal advice, but this is my understanding of the situation with GPL:

• if you distribute something that incorporates GPL software, the compound thing needs to be GPL as well
• when building a Typst document, the resulting PDF does not incorporate any packages (the compilation just executed code from that package) so that's always ok.
• when your package depends on a GPL package and you don't distribute that package (personal or company-internal use) that should also be ok, although I'm not sure where the threshold to distributing lies.
• when you publish your package e.g. to Universe and it depends on a GPL package, I don't think it's clear what that means. To me it would seem that this is kinda similar to linking: you don't distribute GPL code as part of your package, but your code is only functional when combined with GPL code. This does not generally seem to be settled law, and even if linking was settled, the technical details would likely mean that this would still not directly apply to Typst packages.

So I think GPL would mostly restrict you when you make a software that you distribute (not make available as a service) to others and that bundles GPL packages such as CeTZ (for services, AGPL would be the problematic one).

The last bullet point I'm least sure about, and that should be the one most relevant to Typst packages. My gut says a separate package is not distributing GPL software, but I'm not certain of that.

[elfin sparrow]

Now you're a blue you'll probably need to specify which hat you're wearing sometimes 😮

[solid umbra]

im not representing the team

just genuinely concerned cuz licenses are complicated lol

and CeTZ is a very fundamental package nowadays so some care has to be taken here

[elfin sparrow]

:p "the cool maths teacher" Vs "the teacher" :p

[solid umbra]

i guess theres also the fact that CeTZ has other contributors

but i think Apache allows changing license

so that might not be a particular concern

[sullen pivot]

I'm also worried about the infectious nature of GPL

[ornate condor]

tingerrr

[typst-community/valkyrie] Issue opened: #10 Add back `min` and `max` schema parameters

Previously the number, integer, float, string, and array schemas had the parameters min and max.

I propose adding these back, those range checks are fairly convenient, especially combined with z..with(min: ...) for schema adaption. The main downside of not having them now is that nested schema validation cannot perform easy length checks.

[solid umbra]

i think this is akin to the linking problem indeed

and in general it's complicated

in other langs it seems to be mostly consensus that you cant have a dep on something that is GPL without being GPL yourself

and regarding "just executing code"... i mean, i guess that's true but I'd err on the side of caution here

speaking practically, @prime robin would be basically forbidden from using CeTZ

kek

[prime robin]

You have no proof I'm using it

[solid umbra]

kek

[sullen pivot]

bur

[ornate condor]

tingerrr

[typst-community/valkyrie] Issue opened: #11 Add built-in `version` schema and coercion

Add a schema and coercion for the verison type, the coercion should attempt parsing a string into a version before it is validated.

Currently, coercions seem to be infallible pre- or post-transformers, at least in semantics, perhaps a relaxation of this could allow parsing conversions like these to simply be pre-transformers.

[flat bane]

I mean, the "executing, not distributing" thing is basically the reason AGPL is a thing, so I think that point is pretty safe.

[solid umbra]

i wouldnt be so confident , especially because we havent defined "executing" very well here lol

it's not only executing but using functions and data structures from the library

AFAIU AGPL concerns mostly APIs and services which your code has no business with in princple

[flat bane]

I'm talking about a "compiling PDFs as a service" use case here

[ornate condor]

tingerrr

[typst-community/valkyrie] Issue opened: #12 Add schemas for argument sinks

Many package provide argument sinks, which are frequently used to allow passing variadic positional arguments and then fail if the sink contained any named arguments.

Some of these (to be discussed which) should be provided as built in schemas with some default transformers like unwrapping only the positional arguments after the assertions ensured there are no named arguments.

[solid umbra]

yeah AGPL would be relevant in that case , that's true

[ornate condor]

tingerrr

[typst-community/valkyrie] Issue opened: #13 Add named schemas for missing built-in types

Some types, such as gradient, stroke, or even simpler ones like label or selector do not yet have schemas.

Some others which are more complex deserve getting dedicated schemas like validation for queryable element functions, countable element functions etc. (what is internally tracked using traits on elements) should likely be included as choice schemas.

tingerrr

[typst-community/valkyrie] Issue opened: #14 Handle `default` in case of `auto`, not `none`

Currently, the default in base-type is used if it == none or == type(none), ideally this should happen when it is auto, as none means an explicit opt, out in most cases.

I'm unsure whether this is always a good idea, this likely interferes with optional: true too in some way.

[prime robin]

Average "LGTM" on the [phone] PR a few days before opening 1000 issues

[elfin sparrow]

@smoky juniper I imagine a reference to having recently pushed 0.2.0, only to raise issues a couple days after :p

And I think it was important to get 0.2.0 out the way anyway, it felt like it was hanging over me :p

[prime robin]

Github makes reviewing harder than it has to be

You get all commits as one big diff soup

[smoky juniper]

You can go commit by commit(?!). I don't get what you mean.

[prime robin]

Reviewing a million of those is also cumbersome

It was a lot of commits

[prime robin]

You also have to do that manually, back and forth

[elfin sparrow]

(it was 70 I think, and I sometimes commit mid task if I need to reboot my computer or something)

Luckily these tasks can all be done in separate branches

[prime robin]

I recommend trying out jj and embracing atomic commits

[elfin sparrow]

Ooo thanks

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #1 consistently have a blank line at the end of files

it's my understanding that having a blank line/line ending after the last line is a pretty broad convention. For consistency and because I doubt there was any deliberate choice, this adds a newline to the files that missed them

SillyFreak

[typst-community/typst-package-template] Pull request opened: #2 change the license given in typst.toml to match the new license

Commit 7eef73c7 changed the license file, but didn't change the license specified in typst.toml

SillyFreak

[typst-community/typst-package-template] Pull request opened: #3 fix assumed typo "mr-package" vs "my-package"

[flat bane]

(sorry for the spam, I hope the PRs are not too granular, it's just all independent changes)

[prime robin]

Nice template, something I found useful too was default install and uninstall recipes for packages to test especially template packages

[flat bane]

It's not mine but @elfin sparrow's (commit history ), I'm just looking to use it and thus seeing what I'd expect 🙂 I'll look at install and uninstall commands too!

[prime robin]

I have some on typst-community/mantodea

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #4 add a short checklist for what to adapt after using the template

This PR actually has some content.

I think it's useful to have a list of steps necessary to adapt the template for a new package, as those changes are spread across multiple different files and may not be obvious at first.

I thought about adding a line "The Unlicense is usually not the right choice for a package, even though it is used for this package template" but thought I'd first bring it up here as that is more opinionated than the rest of this PR. What do you think?

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Issue opened: #5 What license to use

Disclaimer: I look up licensing when I have to, but have no legal training in this or any other area.

The template is currently using the Unlicense, after previously being under the GPL. I have read (1, which references 2) that Unlicense is too "naive" to really work. There is also the [CC0]...

[prime robin]

PSA @flat bane James seemed to leave the out folder of the example test, likely caused by the missing .gitignore

you can copy the gitignore form here: https://github.com/typst-community/mantodea/tree/main/tests

maybe the .ignore too it's used by helix and some other tools for ignoring certain files in file pickers and searches (this could be in the root too)

[flat bane]

Ah thx, I was wondering about that but don't know enough about typst-test yet 😛

[prime robin]

It'll be better after the rewrite i promise

I'll be adding some plumbing commands to fix projects

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #6 Change ordering of fields in typst.toml (discussion would be useful)

The current typst.toml is missing some optional fields and IMO also orders them in a strange way (for example, there are four keys between keywords and categories, which are both about discoverability of packages via tag-like classifications). This PR changes the order to reflect what's described in typst/packages. It also links that page in the file for reference.

Although the order in the packages repo is a min...

[elfin sparrow]

Do I need to do anything with perms to allow people to merge these?

[flat bane]

I'm not entirely sure how it works but for me to be able to merge my own PRs, @prime robin gave me write permissions on the guidelines repo: #1194684809906237500 message. For merging only other's PRs, triage is probably the correct permission.

In general: do you have reservations regarding how the template develops, or is it more important to you that it's as little work to you as possible?

[elfin sparrow]

No reservations ^^ just didn't want people to assume it was a project I was precious about ;p

[prime robin]

I think I have all ecosystem team members triage access on guidelines

Which gives them stuff like closing PRs and managing labels

[ornate condor]

JamesxX

[typst-community/typst-package-template] Pull request closed: #3 fix assumed typo "mr-package" vs "my-package"

JamesxX

[typst-community/typst-package-template] Pull request closed: #4 add a short checklist for what to adapt after using the template

JamesxX

[typst-community/typst-package-template] Pull request closed: #1 consistently have a blank line at the end of files

JamesxX

[typst-community/typst-package-template] Pull request closed: #2 change the license given in typst.toml to match the new license

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #15 feat(sink): Add schema generator for argument sink types

Implements schema generator for argument sink types, as described in #12.

To do:

• [x] Implement schema generator
• [ ] Implement thorough testing
• [ ] Add to documentation

JamesxX

[typst-community/typst-package-template] Pull request closed: #6 Change ordering of fields in typst.toml (discussion would be useful)

[elfin sparrow]

@prime robin would it be sensible for Valkyrie to use the mantodea package for it's doc generation? And is there a ci script for installing typst dependencies?

[prime robin]

Mantodea doesn't currently do any doc gen, im working on some primitives for defining, definitions, and refernces to those definitions

Which means it could be used for this with some convenient wrapper functions at some point, but right now it can't really

For the latter, I don't think there's a ci action, perhaps you could ask @oblique star to make one for utpm which I believe does this locally already

[ornate condor]

JamesxX

[typst-community/valkyrie] Issue opened: #16 Fix failing CI on building docs

CI automatically builds the docs, which depend on a locally installed unreleased version of mantis. This issue could be resolved by either not requiring that CI successfully compiles the docs, or by some means installing this package during CI.

JamesxX

[typst-community/valkyrie] Issue opened: #17 Feature Request: A means of visualizing a schema and its requirements

This may not end up being possible but I'm creating this issue to track the addition of a means to visualize valkyrie schema for the purposes of inclusion in package documentation.

Current thoughts: Schema define a new method for the purposes of generating content that adequately represents the schema and its requirements. This might only work for the simplest schema without coercions or assertions. Alternatively, this task is left to individual documentation-generator packages as its impl...

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #18 Add named schemas for missing built in types

Added the following missing common types:

• [x] Gradient
• [x] Schema
• [ ] Label
• [ ] Selector

Prior to merge, ensure that:

• [ ] Docs are up to date
• [ ] All newly added types have sufficient coverage in tests

[flat bane]

If anyone is interested, a follow-up on the GPL discussion because I read some stuff about a similar situation* with LaTeX.

The accepted answer is of the opinion that a PDF file is considered "object code" that resulted from compiling LaTeX Typst source code, and if some of that source code is GPL, that means the whole derived work needs to be GPL licensed. Many other users agree, but the discussion under the accepted answer also has doubts that this is the correct interpretation: another interpretation is that the "compilation" is actually interpreting the source files, and the PDF is the output of the interpreted code, not a translated form of the compiled code.

I think it's fair to say that the open source SE community (and the FSF, whose opinion is referenced by the answer) probably has a bias towards the former interpretation; I personally agree more with the latter camp (even though user PhillipPirrip is not convincing to me, Max Xiong makes a good case for that interpretation - no pun intended).

* The two discrepancies are that the post is about LaTeX, and that the code in question is a template that iiuc includes a tex file that would be changed directly; it's not only about using a library.

[sullen pivot]

The FSF is a cult

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #19 Remove docs from CI

Resolves #16

[prime robin]

I think i too agree with the later camp, to me it feels weird to view the output of a GPL program as being GPL licensed too

I don't consider the output of me running ls to be a GPL licensed, nor a script using any coreutil

[ornate condor]

tingerrr

[typst-community/valkyrie] Issue opened: #20 Enhance `content` schema or add a more permissive schema

Currently, with something like z.content I would've assumed to be able to pass sym.dagger, but It turns out this is of type symbol. This makes sense of course, but a user my expect z.content to allow this too.

I think symbol should be added to z.content, as it is trivially converted to content. I wonder if there are any other types we may have missed that ought to be included here.

JamesxX

[typst-community/valkyrie] Pull request closed: #19 Remove docs from CI

JamesxX

[typst-community/valkyrie] Issue closed: #16 Fix failing CI on building docs

[prime robin]

I think those notifs can really shove up important discussions

[elfin sparrow]

Yeah I wonder if it's worth toning them down a bit

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #21 Add back `min` and `max` schema parameters

Resolves #10

[ornate condor]

JamesxX

[typst-community/newsletter] Pull request opened: #1 Addition - Ecosystem - Bevy typst release

Add link to the discord discussion on the release of bevy typst

[ornate condor]

tingerrr

[typst-community/valkyrie] Pull request opened: #22 Fix type mismatch error message

Functions cannot be joined, so they need to be turned into their repr first.

[prime robin]

I am once again recommending jj if you frequently work with more than on PR

I have all PRs merged locally to use them on a package and resolving the minor conflicts was all i had to do

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request closed: #22 Fix type mismatch error message

JamesxX

[typst-community/valkyrie] Pull request closed: #15 feat(sink): Add schema generator for argument sink types

JamesxX

[typst-community/valkyrie] Issue closed: #12 Add schemas for argument sinks

JamesxX

[typst-community/valkyrie] Pull request opened: #23 Bring `next` branch up to date again

JamesxX

[typst-community/valkyrie] Pull request closed: #23 Bring `next` branch up to date again

[prime robin]

What is happening

I cannot follow the history anymore

@elfin sparrow what exactly is this next branch

[elfin sparrow]

yeah I think I goofed it. It my mind next was just the unreleased version

[prime robin]

ah

[elfin sparrow]

sort of like "staging" perhaps?

[prime robin]

i would not maintain that and mrge back and forth

makes it super hard to follow the history

[elfin sparrow]

yeah sorry :/

[prime robin]

a new version just happens as a tag

no worries

I use jj so fixing the repo was easy :)

i.e. my local merge

and since most stuff is merged now I can mostly use main

[elfin sparrow]

yeah I'll merge things into main from now on, less of a headache tbh

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request closed: #21 Add back `min` and `max` schema parameters

JamesxX

[typst-community/valkyrie] Pull request opened: #24 Merge `next` into `main`

Fewer headaches

JamesxX

[typst-community/valkyrie] Pull request closed: #24 Merge `next` into `main`

[ornate condor]

JamesxX

[typst-community/valkyrie] Issue closed: #10 Add back `min` and `max` schema parameters

[oblique star]

More or less, yes

I can try yeah but I know nothing about GitHub actions

[prime robin]

How's the maintenance status of utpm looking

[oblique star]

For now, I've paused the project because I don't have really much time

[prime robin]

I see

Are you available to merge fixes and features?

[oblique star]

Not really :/

I'll try this month to add the missing features

[prime robin]

I've opened an issue yesterday you could take a look there why I'm asking as well as suggestions about maintenance

[oblique star]

i'll check it later, thx

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #25 Add symbol to allowed types for `z.content`

Resolves #20

tingerrr

[typst-community/guidelines] Pull request opened: #6 Add api section about interoperabilty

This PR adds a section to the API part which explains different kinds of considerations to take to make a package API more interoperable.

Right now, this mainly contains a section about state, counter and label keys.

I think there's more to be researched and said, I want to look at polylux, touying and tablex for their cetz integration, as well as fletcher for its extension of cetz and escape hatch mechanism. All of these are good examples of interoperability that is not yet written dow...

tingerrr

[typst-community/guidelines] Pull request opened: #7 Add section about internal and public parameters

This PR expands the API flexibility section regarding internal and public parameters and how they can be used to keep an API both flexible and efficient with the right choice of internal vs public parameters.

tingerrr

[typst-community/guidelines] Pull request opened: #8 Add api and style section about documentation

This PR adds both a style and an API section on documentation comments, the style section takes inspiration from Tidy's syntax and suggestions by the tinymist author regarding simplicity.

I'd like to get some input from @Mc-Zen and @Myriad-Dreamin regarding syntax.

I have not yet included things like tests, examples and other annotations, and I'd like to know what you guys think are sensible in the constraints of LSP and Tidy.

It would be great if we could choose a formal syntax for ...

tingerrr

[typst-community/guidelines] Pull request opened: #9 Switch `typ` raw lang annotation to `typst`

This mainly helps with the lack of support for some editors, which may expect typst instead of typ.

tingerrr

[typst-community/guidelines] Pull request closed: #9 Switch `typ` raw lang annotation to `typst`

JamesxX

[typst-community/valkyrie] Pull request closed: #25 Add symbol to allowed types for `z.content`

JamesxX

[typst-community/valkyrie] Issue closed: #20 Enhance `content` schema or add a more permissive schema

[elfin sparrow]

bless you 😛

[prime robin]

😂

jj autogenerated

[solid umbra]

It can do that?

[prime robin]

yeah

jj git push -c <changeid> and it'll generate an push a branch named push-<changeid> at this id

i pushed 4 PRs at once simply by passing this four times

[solid umbra]

wow cool

[prime robin]

the prefix can be configured

[solid umbra]

too bad i don't use jj git lol

It doesn't like interactive ssh password

[prime robin]

it soon will

[solid umbra]

I hope so

Maybe I can work around it if I find a way to have ssh ask in a GUI or something instead

[prime robin]

it's just that they use libssh currently

which doesn't respect the ssh config

but saw that there is some work on making this work

namely an update to libgit2 i believe

[solid umbra]

Well, we will be watching their career with great interest

[prime robin]

ah here it is: https://github.com/martinvonz/jj/pull/3191

[solid umbra]

Noice

I think it works for ssh agents but i don't know how they work so unknown is scary

In particular i know that ssh agent forwarding is bad and scary

[prime robin]

cc: @daring nymph @tough crown

I've tagged both of you on the PR for feedback, but I know ping notifs can get lost quickly on github.

[daring nymph]

I'm recently busy on my real life, and I'll back to read it once I'm freed.

[prime robin]

no hurry I made all these because I'm gone for a week

[solid umbra]

Nooooo tinger don't spontaneously disintegrate for a period of 7 days

[prime robin]

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #26 Revert to default if `auto` is given

As described in #14, if the tested value is auto the following changes now apply:

• If default is set, it is applied on auto
• If default is not set, but optional is true, the tested value is parsed as none without failing
• If there is no default and it is not optional, an assertion error is thrown

There don't appear to be any regressions but this is a breaking change so its something to keep in our minds if something starts going fucky-wucky later down the line.

Resolve...

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request closed: #26 Revert to default if `auto` is given

JamesxX

[typst-community/valkyrie] Issue closed: #14 Handle `default` in case of `auto`, not `none`

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #7 ignore test out and diff directories

patterns taken from https://github.com/typst-community/mantodea/tree/447df617e5ed950abc7f81b2e67521874437ca17/tests

the out/ and diff/ directories contain images that don't need to be committed, as they're just created by typst-test to compare to the expected ones in ref/

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #8 Add commands for local install and uninstall

This PR adds two scripts adapted from CeTZ (Apache 2.0): https://github.com/johannes-wolf/cetz/blob/35c0868378cea5ad323cc0d9c2f76de8ed9ba5bd/scripts/package

# locally installs under the name `@local/package`
just install
just uninstall

# locally installs under the name `@preview/package` (i.e. lets you test code that contains imports of the published package)
just install-preview
just uninstall-preview

JamesxX

[typst-community/typst-package-template] Pull request closed: #7 ignore test out and diff directories

[oblique star]

@prime robin Hey, sorry to bother you but I came across this library, do you think I can you that to create the command publish on utpm?

[ornate condor]

JamesxX

[typst-community/typst-package-template] Pull request closed: #8 Add commands for packaging and local install/uninstall

mindbound

[typst-community/valkyrie] Issue opened: #27 Mutually exclusive choices in `either`

Is it possible to set either to have mutually exclusive choices, e.g. where only one of

let schema = val.either(
val.dictionary((
dynamic: val.boolean()
)),
val.dictionary((
seed: val.integer()
))
)

can be the case but not both?

[prime robin]

Possibly, I don't have time to look at it too thoroughly right now

[oblique star]

No problem, thx!

[ornate condor]

pklaschka

[org] New discussion #10: Unified Standard Elements Enhancement Package

Based on my recent showcase on the Typst Discord Server of enhancing the standard #image element (see the example below), I'd like to open a discussion on whether there should be a unified "standard element enhancements" package maintained under this GitHub organization and overall governed by the community. While I'm not sure yet if that's a good idea, I have come to believe that it would be a terrible idea to have these kinds of enhancements be individual packages.

Proposal

Consi...

[ornate condor]

jneug

[typst-community/valkyrie] Issue opened: #28 Make tuple fail gracefully for wrong number of values

The tuple type currently throws a somewhat confusing error message when the input has to few values, while it passes for inputs with more values than expected.

See this example:

#{
  let schema = t.tuple(t.integer(), t.integer())
  t.parse((0, 1, 2), schema) // passes
  t.parse((0, 1), schema)    // passes
  t.parse((0,), schema)      // fails with error
}

The first call to parse throws this error:

error: array index out of bounds (index: 1, len: 1) and no d...

jneug

[typst-community/valkyrie] Issue opened: #29 Allow default values to use other values

I would like to be able to set the default value of one value to be the same as the value of another argument, or use that value somehow.

For example, if I wanted to create a create-theme function that creates a color theme with a primary, secondary and tertiary color:

#{
 let theme-schema = t.dictionary((
    primary: t.color(),
    secondary: t.color(optional: true),
    tertiary: t.color(optional: true),
  ))

  let create-theme(primary, ..args) = {
    let theme =...

[ornate condor]

jneug

[typst-community/valkyrie] Issue closed: #29 Allow default values to use other values

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request closed: #18 Add named schemas for missing built in types

JamesxX

[typst-community/valkyrie] Issue closed: #13 Add named schemas for missing built-in types

[ornate condor]

jneug

[typst-community/valkyrie] Issue opened: #30 Add types and coercions for "variable" types like stroke and fill

#18 added a schema for the Typst builtin type "stroke". But most of the time stroke arguments accept either one of stroke, length, color or dict. Similarly fill usually accepts color, gradient or pattern.

There should be types to support this, since those are very common use-cases in Typst.

I suggest these compound types:

• strokes: z.either(z.stroke(), z.length(), z.color(), z.dictionary( (thickness: z.length(optional:true), ...) ))
• fill: `z.either(z.color...

JamesxX

[typst-community/valkyrie] Pull request opened: #31 Error properly on tuple length mismatch

Tuple schema now properly requires the length of a tuple to exactly match in order to validate. New behaviour can be disabled by setting exact to false.

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #32 Changes to `either` and `dictionary`

• Dictionaries now take a strict context parameter (defaulting to false) to check in all fields in given dictionary are present in the schema and vis versa (previously, it only checked if all the schema entries were present in the given dictionary)
• The either schema generator function now takes a parameter strict (defaulting to true) to set the strict context parameter on its children. This is a breaking change that fixes the bug you've brought up
• Dictionaries previously blinded...

[ornate condor]

SillyFreak

[typst-community/setup-typst] Issue opened: #21 Allow specifying the name of the installed Typst executable

this action adds typst to the path; for testing packages with multiple Typst versions it would be desirable that different versions could be installed under different executable names, to that in the end for example typst and typst-0.10 end up on the Path.

I can imagine a few different ways this could work:

• add a parameter like executable-name that you could set to typst-0.10. If specified, the executable is renamed
• add a parameter like use-version-suffix that you could s...

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #9 Improve CI workflow with Typst version matrix

This PR updates the actions used by the template's GH Actions workflow. In addition, it uses a version matrix to run tests on multiple Typst versions. The docs are still built as part of the test workflow to make sure it builds, but this is only done on the latest version (or whichever is specified) because the package can be compatible with a specific Typst version even if the docs are not.

SillyFreak

[typst-community/setup-typst] Issue closed: #21 Allow specifying the name of the installed Typst executable

SillyFreak

[typst-community/setup-typst] Issue closed: #21 Allow specifying the name of the installed Typst executable

[ornate condor]

JamesxX

[typst-community/typst-package-template] Pull request closed: #9 Improve CI workflow with Typst version matrix

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #10 fix package script to include hidden files (unless ignored)

using * to move all files in a directory is faulty because * does not enumerate hidden files. use shopt -s dotglob to fix this

[ornate condor]

JamesxX

[typst-community/typst-package-template] Pull request closed: #10 fix package script to include hidden files (unless ignored)

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #11 Add release workflow

This adds a second GH Actions workflow that prepares a release of the package:

• the workflow runs on pushes to tags starting with v...
• the version number in typst.toml is checked to match the tag
• the package's docs are recreated and the package is bundled for universe (just doc, just package)
• a user-specified repo (should be a fork of https://github.com/typst/packages/) is checked out
• the package is added to it at the right path (packages/preview//)
• the changes ar...

[prime robin]

@tough crown hey I wonder if you had some time to look at the PR I mentioned you in regarding doc comment syntax

[daring nymph]

I left some comments here, https://github.com/typst-community/guidelines/pull/8. I put most comments on syntax (style), and I didn't make much comments on the principle of making nice documentation.

[tough crown]

Oh thanks for pinging me again. I forgot about it and will comment today

[ornate condor]

tingerrr

[typst-community/guidelines] Issue opened: #10 Chose appropriate license

A suggestion by @PgBiel was CC-BY 4.0.

[ornate condor]

tingerrr

[typst-community/guidelines] Pull request closed: #7 Add section about internal and public parameters

[ornate condor]

tingerrr

[typst-community/guidelines] Pull request opened: #11 Add CC BY-SA 4.0 LICENSE

Resolves #10.

[ornate condor]

JamesxX

[typst-community/newsletter] Pull request opened: #2 Add Shiaroa:0.1.0 to packages section

[dense vale]

@elfin sparrow if you are looking to automate some parts of the newsletter idm putting in some time onto such automation to help out

[elfin sparrow]

That would be awesome! Just trying to get the ball rolling at the moment more than anything

[dense vale]

awesome, glad to know

[prime robin]

do forks of repo templates inherit their labels?

[dense vale]

weren't they stored in the .github/ folder?

[prime robin]

is that how it works?

[dense vale]

not affiliated with tweag, but i stumbled on this one time https://github.com/tweag/project/blob/master/.github/settings.yml

[prime robin]

huh

interesting

[dense vale]

other than i guess it might inherit from the organization maybe?

not sure

see https://docs.github.com/en/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization

[prime robin]

I was just wondering because i configured those for typst test today and was wondering if the package template should have some default ones

[dense vale]

might be convenient i guess yeah

it wont be too inconvenient if the author wants to remove them

[flat bane]

yeah, sounds useful. checking the appropriateness of the label could also be put in the adaptation checklist

[dense vale]

I'm thinking of setting up the organization's CONTRIBUTING.md.

this is an outline i have currently:

Getting Involved

Document Synopsis

Projects

Proposing a New Project

I think having a place for people to collab on project ideas might be interesting so this section is for that

Contributing to Existing Projects

• Emphasis on CoC
• Where to report what
• Linking to an organization-wide issue-board (provided by github)

Transferring a Project

Linking to the transfer template on the discussion board

Becoming a Project's (co-) Maintainer

Not sure yet about how we should do this, so it'll be omitted unless someone has a good idea.

Organization

Community-Wide Suggestions

guidelines, best practices etc?

Community Health

Discussions regarding policies, governance, coc etc.

Organization Image

Branding (e.g logo, website, advocacy etc)

--
would love to get your opinions to hopefully improve this outline. Given it's going to be for the "get involved" call to action you see on the organization-wide readme.

[prime robin]

Organization could have an outline of teams and what they are trying to work on

[dense vale]

in the CONTRIBUTING.md? i do that in GOVERNANCE.md atm

[prime robin]

oh right

[dense vale]

https://github.com/typst-community/org/blob/main/GOVERNANCE.md

[prime robin]

I'm unsure if organization is part of contributing then

[dense vale]

it's primarily for meta files, how do you propose changes relating to the organization than any specific project?

do keep in mind that this CONTRIBUTING.md is strictly for the typst-community/org repository, so it won't show anywhere, but this repository unlike the CoC stored in typst-community/.github

[prime robin]

mhm

ok that makes sense

[ornate condor]

SillyFreak

[typst-community/guidelines] Pull request closed: #11 Add CC BY-SA 4.0 LICENSE

SillyFreak

[typst-community/guidelines] Issue closed: #10 Chose appropriate license

[ornate condor]

jneug

[typst-community/typst-package-template] Issue opened: #12 Do not exclude README.md

I just got a comment on a package I initialized with this template that README.md should not be excluded. I guess the same goes for CHANGELOG.md.

[ornate condor]

dyc3

[typst-community/setup-typst] Issue opened: #22 Support for aarch64

Ran into this issue when setting up a self-hosted runner on an M1 mac mini. The action downloads the x86_64 version of the typst binary when run on an aarch64 system. When attempting to run the executable, I get bad CPU type in executable.

[ornate condor]

dyc3

[typst-community/setup-typst] Issue closed: #22 Support for aarch64

[ornate condor]

SillyFreak

[typst-community/typst-package-template] Pull request opened: #13 don't exclude README and CHANGELOG (and also Justfile)

this removes the three items from exclude in typst.toml. The former two should be part of the published package; the latter should not even make it into the PR to universe and thus doesn't need to be excluded.

A possible alternative point of view is that the package script which uses .typstignore should not be assumed, and thus things like tests and Justfile should be put into exclude. Personally, I think that even when not using that script, these things don't belong into the ...

[ornate condor]

jneug

[typst-community/valkyrie] Issue opened: #33 Should coercions respect `optional: true`?

Not sure if this is intended, but currently coercions will panic if a value is none, which can happen with optional: true set.

I think it would be more intuitive, if a coercion respected the optional setting and returned none, if the key was not present.

For example, the array coercion would look like this:

#let array(self, it) = {
  if self.optional and it == none {
    return none
  }
  if (type(it) != type(())) {
    return (it,)
  }
  it
}

[elfin sparrow]

What would people think of a style recommendation of avoiding absolute paths in packages? I needed to copy over main version of cetz and I spent way too long updating filepaths in includes

(a problem which can be avoided with relative paths)

[flat bane]

I personally like to use them for docs and tests: import "/src/lib.typ" instead of import "../src/lib.typ" but other than that it's probably a good general recommendation.

[prime robin]

Feel free to open an issue or PR on the guidelines repo outlining those points

this would also be easier ot fix if LSPs had a rel to abs path conversion action

for which we could create a feature request

I personally find relative imports horrendously ugly, but it is what it is

[elfin sparrow]

Will do, just wanted to smoke test the suggestion first

[prime robin]

at least those that go up a directory ore more

[elfin sparrow]

Truly, but they sure are convenient :p

[prime robin]

yeah ofc, but idk if vendoring is all that common

I'd argue we're trying to avoid people needing to vendor a package in the first place using these guidelines

Regardless, I think it's overall better to have something more funcitonal even if it's uglier.

[smoky juniper]

Cetz ships with a script to do that for you. With just package --relative-paths <target> (not tested) you can copy the cetz package to the target dir, with all imports relative, so you should be able to import it in your project.

[elfin sparrow]

Requires just to be installed which isn't possible on institutional computers tho

[prime robin]

But typst is?

[elfin sparrow]

Yeah typst has a web app

?

[prime robin]

Oh ofc

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request closed: #32 Changes to `either` and `dictionary`

JamesxX

[typst-community/valkyrie] Issue closed: #27 Mutually exclusive choices in `either`

[dense vale]

🗿

[prime robin]

🗿

[smoky juniper]

If python is installed you can run the script directly.

[ornate condor]

JamesxX

[typst-community/typst-package-template] Pull request closed: #13 don't exclude README and CHANGELOG (and also Justfile)

JamesxX

[typst-community/typst-package-template] Issue closed: #12 Do not exclude README.md

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request closed: #31 Error properly on tuple length mismatch

JamesxX

[typst-community/valkyrie] Issue closed: #28 Make tuple fail gracefully for wrong number of values

JamesxX

[typst-community/typst-package-template] Pull request closed: #11 Add release workflow

[native loom]

request: allow this channel to be searchable so I can find whether Docker was mentioned here

[dense vale]

seems to work? 🗿

i guess you can do in:forge to filter cant seem to get it to specifically target this thread

[ornate condor]

m-haug

[typst-community/valkyrie] Issue opened: #34 Tuples do not respect optional elements

I'm trying to parse a schema with an optional trailing content using tuple. However, when I use a schema like

tuple(string(), string(), content(optional: true))

valkyrie panics when trying to access the third element of the tuple if the trailing content is not specified.

[ornate condor]

tingerrr

[typst-community/valkyrie] Issue opened: #35 Regression for `auto` in handled like `none`

It seems that c52ae78e1d73105dfc432611e2c790bbf3c12645 introduced a regression where, given an either schema containing an auto schema, passing auto actually fails with an incorrect message saying it got none.

#import "@preview/valkyrie:0.2.0" as z

#{
  _ = z.parse(auto, z.either(
    z.content(),
    z.base-type(name: "auto", types: (type(auto),)),
  ))
}

I haven't actually tested this specific snippet, it's a minified version, I've done the bisection on th...

[ornate condor]

jneug

[typst-community/valkyrie] Issue opened: #36 Improve introspection of types

I'm in the process of implementing a basic visualization of valkyrie schemas for my documentation template (like suggested in #17). It won't cover every possible case, but can be used as a means to define custom datatypes.

Some of the provided types don't expose all necessary information for this, though. For example #choice(list) "hides" the list of possible choices in an assertion closure.

It would be nice if types made all important information available (like in the example above in ...

[ornate condor]

jneug

[typst-community/valkyrie] Pull request opened: #37 Adds the list of choices to the `choice` type

This allows access from other packages / templates to the list of choices available for this type.

[elfin sparrow]

I might suggest we silence notifications from the Valkyrie repo as I'm starting to feel like it detracts more than it adds to this channel

[dense vale]

it'll silence all repository pull requests and issues in that case

the granularity isn't offered unfortunately

[prime robin]

I don't think they're all that helpful really

Up to you guys

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request closed: #37 Adds the list of choices to the `choice` type

[ornate condor]

JamesxX

[typst-community/valkyrie] Pull request opened: #38 36 improve introspection of types

This PR adds a description field on base-type, which serves to take the descriptive burden off name so that it can more properly be used to identify types for the purposes of rendering them.

To do:

• [ ] Update changelog to reflect any breaking changes

[dense vale]

updated, excludes prs and issues now

discussions are fine for now?

[prime robin]

Sounds good

[prime robin]

@elfin sparrow how often do you intend to publish the newsletter and how?

I wanted to add two of my releases but sawy there were 2 open PRs for like 3 weeks now

[elfin sparrow]

I think monthly is probably good for the moment, but I was only getting the ball rolling so feel free to run with any changes you think need making

I think adding your release would be good!

[elfin sparrow]

I've been using Jekyll for my programming blog - do you think it would also be suitable for the newsletter?

[elfin sparrow]

w.r.t the template repo, I cant seem to get the release workflow working

I keep ending up with remote: Permission to JamesxX/typst-packages.git denied to JamesxX. fatal: unable to access 'https://github.com/JamesxX/typst-packages/': The requested URL returned error: 403

I've followed the instruments (to the best of my interpretation) so I'm a bit stuck

nvm I figured it out

I was selecting the package repo rather than the typst-packages one

[prime robin]

you selected that repo for the token i assume?

since the repo url was correct in that message

btw guys I would appreciate a review on the two guideline PRs, i fixed some grammar and spelling stuff today, but I'm sure i missed stuff

they're about package interop and doc comments

the doc comments may seem a litte outlandish at this moment but I've tried to closely work with the tinymist and tidy author respectively to hash out the details

[elfin sparrow]

yeah I borked up, I was simply selecting the wrong repo when creating the permissions 😛

[elfin sparrow]

sure thing

[elfin sparrow]

Some thoughts I had when writing my blog post: is it possible to have the typstignore file a section in the typst.toml manifest instead?

[prime robin]

I don't think this is a file that's even the exists now

[elfin sparrow]

And: is it worth having a fork for templates specifically?

[elfin sparrow]

Yeah the package script looks at it to figure out which files not to package

[prime robin]

Ah

[flat bane]

yeah, that's (among other things) the stuff that we discussed is getting "out of hand" in shell. As I said in the Showcase, I'll RIIR over the summer.

[prime robin]

I figured that was more of a future proofing kinda thing

[flat bane]

in the rewrite I see no problem replacing that file with a tool section. I'm writing something right now that uses a tool section, so I'm getting some experience

@prime robin, I assume the typst-kit is still a bit too far off to use that for accessing the tool section, right?

btw, if someone here has experience with distributing (Rust) binaries I'd be happy to have some help there. I have no problem writing the code, but there's probably some "release Rust binaries for multiple platforms so that users can install it easily" know-how here that would be nice to reuse.

[prime robin]

The tool section will be available soon in typst-syntax

See my latest draft or on typst

In the interim you could already use my unstable typst-project repo, but it's supposed to be superceded by typst-kit so I'm not planning to maintain that further

It's also a little over engineered and less error resistent in terms of manifests parsing

[prime robin]

Someone, and I forgot who it was but I'll find out, has suggested packaging things with pix which is apparently a conda based tool

It installs tools and dependencies and stuff

[flat bane]

https://discord.com/channels/1054443721975922748/1255426451243536464

[prime robin]

I believe it was @worn lava

[flat bane]

yep

[prime robin]

Yeah

[flat bane]

the mention of conda made me a bit uneasy. Does that mean it has a dependency on Python, and/or a tight relationship with Python packaging? I always have the feeling that Python's packaging story is not exactly a clean best practice to follow... But maybe, if you look at conda without preconceptions it's better than that superficial impression.

[worn lava]

conda was originally developed to solve the problems with packaging binary python packages that weren't adequately solved by pythons native packaging system, but has since expanded to packaging pretty much anything.
pixi is a modern package manager inspired by cargo that installs conda packages without using conda itself. Pixi is written in rust and is a single binary without external dependencies.

[flat bane]

that's good to hear, I initially assumed it required a miniconda install at the minimum.

so basically for our purposes, it would give you cargo install or cargo binstall-like capabilities while requiring only a single binary to download instead of first having people rustup if they don't have Rust already - is that about right? (I'll re-read your showcase in case it's already in there)

[worn lava]

Basically yes, but you can't just install a cargo package. Someone needs to have packaged it on conda-forge (Which for rust programs is very simple. Everyone can submit packages as a pull request to https://github.com/conda-forge/staged-recipes/).
The advantage over cargo install/bininstall is that you can have isolated, per-project dependencies, dependencies are locked to a specific build for reproducibility and there is a built-in task runner.

[prime robin]

That it's also a task runner made me a little uneasy at first, but it makes sense considering you want to ensure running the right binaries per project

[worn lava]

It basically saves you enabling your virtual environments. Instead of enabling your env, then running your command, then potentially deactivating it again you rust run pixi run ...

[prime robin]

Yeah I get that, it's similar to rye in that regard

Very handy for sure, I just had less use for it since I don't have as many per project tools

[prime robin]

cc: https://github.com/typst/typst/pull/4494

The ToolInfo struct contains an example of how to use it too.

It should be as easy as defining a serde struct and deserializing it from the Table in the section

[elfin sparrow]

On the guidelines repo, there's an issue about choosing another template

These past few days I've made a springer book chapter esque template that I think might be suitable

https://github.com/JamesxX/springer-spaniel

[prime robin]

I'm already working on one tbh

a fork of mantys

typst-community/mantodea

[prime robin]

@elfin sparrow what were you looking for regarding valkyrie#39?

[elfin sparrow]

its been a while since I touched it so mainly it was "is there anything critical that would stop a release"

also, I'd like to move valkyrie over to the new package template, and I have questions about the token stuff. Would typst-community need its own typst-packages repo?

[prime robin]

are there any features or so? seems you want to relaese a patch from looking at the milestone

[elfin sparrow]

It's mostly been additions of types and minor tweaks to the internals

[prime robin]

should be a minor release then

[prime robin]

that's a good question

I forgot if it creates the PR too or just the push the to fork

[elfin sparrow]

it just pushes to the fork

[prime robin]

then it won't matter if it's your fork or typst-community's

[elfin sparrow]

how would we create the PR? I'm not up to speed on how orgs work in that respect

[prime robin]

I'm unsure

@dense vale might know more about this

cc: @flat bane

[elfin sparrow]

ideally I'd like it to be entierly doable without me for when I'm in a busy period, and I don't think that'll be the case if the typst-packages fork is on my account

[prime robin]

TLDR: the auto push to fork workflow is nice but we don't know how well it'll work from the community org perspective

[elfin sparrow]

yup

in meantime, I'll push over the template files because we'll need them one way or the other

noticed that @civic perch has made contributions but isn't listed as an author - would you like to be listed in the package manifest?

[prime robin]

on which one

[elfin sparrow]

valkyrie

it must have been for a PR

https://github.com/typst-community/valkyrie/commits?author=jneug 😛 this

[civic perch]

It's fine. I don't need to be listed.

[elfin sparrow]

Fair, just want to give you the opportunity if you wanted it

[dense vale]

is the question in regards to creating a new typst-packages repository in the typst-community organization for the releases of packages in the typst-community?

[prime robin]

It's more so if one could make PRs from the org repo

[dense vale]

oh

that makes sense

[prime robin]

or if james could make the pr himself from a fork in the org itself

which ever makes the most sense i suppose

[dense vale]

valid question

bothway works really, the only difference is where the patch is coming from which shouldn't really matter if the person submitting it is an author or acting on behalf of the author.

i see a potential in contributors having to work in a single branch rather than different forks tho so @elfin sparrow @prime robin i think it would be great

[elfin sparrow]

my brain is in sunday mode: does that mean typst-community/typst-packages repo?

:L

[dense vale]

yes

[elfin sparrow]

cool cool 🙂 I don't have perms for that I don't think - can you set one up and generate a permission token for valkyrie's github aciton? needs read/write on contents on typst-package

[dense vale]

https://github.com/typst-community/packages

[elfin sparrow]

Ooo

[dense vale]

how do i make the permission token?

[elfin sparrow]

https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization

I think this?

[dense vale]

🤣

had it ready it seems

oh its in the organization?

[elfin sparrow]

I was trying to figure it out for myself and must have figured I had found an answer 😛

[elfin sparrow]

I think so. I can't create an access token on my own account for a repository in an organisation it seems

[dense vale]

🗿

okay so it seems like you have to make a request?

[elfin sparrow]

thanks I'll see what I need to do on my end now

2 mins

[dense vale]

i've disabled the classic version, but if needed we can reenable

[elfin sparrow]

no I think its the new version we want

I've sent a request I think

[dense vale]

got it

looks correct

approved

[elfin sparrow]

Ready for a test? We might need to end up deleting messed up branches on the packages repo

[dense vale]

gogogo

the only thing i wish we could do is restrict the access token to a single branch

so in the future it doesnt become a mess in the case somebody deletes something on accident

[ornate condor]

JamesxX

[typst-community/valkyrie] New release published: v0.2.1

[elfin sparrow]

I don't think that would work either because each branch is named after the package and its version

speaking of, is it possible for the publish script to detect whether the branch already exists and delete it first if so?

[dense vale]

probably using git

[elfin sparrow]

That makes re-doing messed up publishing easier

[dense vale]

u can add a step that queries the branches and checks for it

we should probably make this into re-usable action right?

[elfin sparrow]

never seen this before 👀

[dense vale]

is it the mktemp?

[elfin sparrow]

is it this? https://github.com/orgs/community/discussions/26239#discussioncomment-3250911

[dense vale]

interesting i thought it'd be a different error not that

but

sure try it

git update-index --chmod=+x

[ornate condor]

JamesxX

[typst-community/valkyrie] New release published: v0.2.1

[elfin sparrow]

attempt number 2 😛

so the permissions thing we were talking about earlier may be more complicate than we thought?

does my account need write permissions to the packages repo?

or branch-making perms

[dense vale]

AAAAAAAAAAAAAAAAAAAAAAAA

you have write permissions no?

[elfin sparrow]

I thought I did

you might need to update the perms on the packages repo itself too

[dense vale]

let me check how you are doing the push right now

where are you passing the token?

[elfin sparrow]

repository secrets

[dense vale]

in the workflow

[elfin sparrow]

https://github.com/typst-community/valkyrie/settings/secrets/actions

[dense vale]

REGISTRY_TOKEN?

but you only check out with it you don't actually use it to push no?

[elfin sparrow]

https://github.com/typst-community/valkyrie/blob/main/.github/workflows/release.yml#L58

yeah we use it to push too

https://github.com/typst-community/valkyrie/blob/main/.github/workflows/release.yml#L77

[dense vale]

there's only one reference to REGISTRY_TOKEN

it's in the checkout phase

[elfin sparrow]

should we add this? git remote set-url origin https://[idk what goes here]:<MYTOKEN>@github.com/typst-community/packages.git

[dense vale]

huh so it should've worked if you specified the token no?

🧠 -> \🧠

[flat bane]

Interesting issues. I'm on mobile so can't help much but during my testing in development the token used at checkout was enough. Does it have write perms?

[flat bane]

I've also used the action in an organization, I can look at the details later but it worked. But I'm also an admin of that org so things may be different....

[dense vale]

the perms look fine

[flat bane]

Yep

[dense vale]

is there a separate permission for creating a branch?

ah there was

you need to also select the Contents permission

nothing else looks relevant?

[flat bane]

Yeah contents should be enough

[elfin sparrow]

yeah thats already set

[dense vale]

oh you set it already

can you try the flow locally?

with the PAT instead of your ssh key

[elfin sparrow]

on the packages repo, try giving my account (james xx) permissions and let me re-run the workflow, I want to see if it makes a difference

[dense vale]

it probably will

[elfin sparrow]

k one sec

[ornate condor]

huwaireb

[typst-community/packages] New collaborator added: JamesxX

[dense vale]

removed you so you can test the PAT

but ill add you if nothing works out

[elfin sparrow]

no the workflow still fails

[dense vale]

okay i'll just add you then if @flat bane has any leads we can go off there later

[ornate condor]

huwaireb

[typst-community/packages] New collaborator added: JamesxX

[elfin sparrow]

I'm going to try updating the script

[ornate condor]

JamesxX

[typst-community/valkyrie] New release published: v0.2.1

[dense vale]

worked it seems

[elfin sparrow]

woop

gosh theres loads of new packages in the queue, monday is going to be like christmas

[elfin sparrow]

@flat bane Et tu? :p

That's a pretty template ^^

[flat bane]

thanks 😊 I wanted to get it in quickly before "Christmas" 😛

[elfin sparrow]

Wonder if there should be a picture gallery of "new templates" in the newsletter

[flat bane]

It's a recreation of our LaTeX template (it's renderd here with a sans serif font; on Overleaf I have it configured for serif). I'm pretty satisfied with how well I was able to replicate it. The biggest problem was IMO that automatically skipping headers and footers on empty pages doesn't work yet; that requires some boilerplate from the thesis authors.

[flat bane]

ok, looking through the actions logs I see nothing interesting... I would have assumed that, if James doesn't have write permissions on the repo, putting the token into the remote URL wouldn't have changed the situation.

The clean way is probably to create a typst-community-bot account or something like that: https://github.com/actions/checkout/blob/main/README.md?plain=1#L36-L37

We recommend using a service account with the least permissions necessary. Also when generating a new PAT, select the least scopes necessary.
But that doesn't address whatever was the underlying issue; it's just hoping that the same doesn't happen with the new account...

[elfin sparrow]

Idea: how possible would it be for the release script to also add an entry to the current newsletter draft?

[prime robin]

That would lock the structure of the newsletter in

Any change could break the script

Edge cases too

[elfin sparrow]

Fair, I'll look into generating a list based on the newsletter side then from the commit history on the registry

[elfin sparrow]

Christmas is upon us

[oblique star]

Update index? What is it?

[prime robin]

Should do the same as chmod +x <file> && git add <file>

[oblique star]

love u

thx!!

[granite ember]

(i'm @oblique star my account has been desactivated for no reason)

Just here to say that tinger your package typst-project is amazing

I've added to utpm without any efforts

[flat bane]

hey, nice that you're here! I'm planning to port some scripts used by typst-package-template to Rust some time this summer. I wondered if you would be interested in having that integrated into utpm. Concretely, the features I'd be interested in adding would be

• collecting the files that should go into a PR to typst/packages (e.g. skipping tests and other development-only files)
  • for that purpose, reading a [tool.utpm] section with its own exclude field
• collecting the files that should go into the actual packages (i.e. additionally using the package.exclude field in typst.toml)
• allowing installation under the @preview prefix (and possibly arbitrary ones) in addition to @local, which helps with pre-release testing

from skimming the utpm source code (though I was on the main branch), it seems that installing-wise your focus is on linking. Would you consider the features I described fitting for utpm?

[granite ember]

First of all, thank you for your time!
The main branch isn't updated for now, I'm working a lot on the dev

I like the idea of collecting files and it could be a nice feature to add, but why creating an other field exclude? package.exclude seems to do the work. I'll add it to my todo list!

In the actual implementation, I don't block namespace to be only @local but everything you want in the [tool.utpm].namespace! But allowing creators to create a pre-release seems to be a good idea!

[granite ember]

I found that we can create automatic pulls to typst/packages, if we combine collecting files + automatic PR when using a flag like release that can lead to a better automatisation. What do you think?

[flat bane]

but why creating an other field exclude? package.exclude seems to do the work
They do different things, as I described: you have files that you should not put in your release PRs, and you have files that should go in there but don't need to be served to users importing the package.

[granite ember]

Understood! I see the idea, like a dotenv file

[flat bane]

the template has a github action that helps with automatically releasing: https://github.com/typst-community/typst-package-template/blob/main/.github/workflows/release.yml - see also James' blog: https://jamesxx.github.io/blog/2024/07/09/packages.html#the-release-workflow

Do you mean something like that? Although the last mile (actually creating the PR against typst/packages) is not automated - which is maybe not that bad.

[granite ember]

More or less! I've just read it quickly but yes it could be something like that but you add automatic PR to typst/packages. I don't know if we can make this workflow and utpm compatible but if we can, it could be a good integration for the dev.

Edit: I've just saw .typstignore exist. Could be a good idea to add support to it since people might use it already.

[dense vale]

Renewal for the domains i coped up last year for typst-community are coming up in two months, i'm renewing typst.community there's no issue there, however thought i should mention i also coped up (was a deal) typst.xyz which i'm letting it expire given i have no use for it, if anyone's interested in the domain i'd be happy to transfer it over free of charge, but you'll be taking over the renewal costs depending on your domain registrar.

[flat bane]

.typstignore is only a month or so old, and the current implementation is limited anyway. I'll go to bed but I'll link you to earlier discussions regarding the template that prompted me looking into utpm for this stuff in the morning.

[granite ember]

Ooooh okay, no problem have a good night!

[sullen pivot]

I'm salty that someone owns typ.st but is doing nothing with it

[dense vale]

damn that would be a lot better than the current typst.app

[sullen pivot]

I'm sure they would ask for a lot of money if they tried to buy it

[dense vale]

yeah registered in 2020 looks unrelated to typst

[sullen pivot]

It's related to typeset.io, which changed their name to scispace

[dense vale]

🗿 typeset -> typ.st?

and they didnt even retain the name 🗿 but RENEWED?

[sullen pivot]

Yeah I dunno, that's who owns it at least

[dense vale]

lmao typset -> scispace must be the worst rename ever

[sullen pivot]

Well typeset is sorta generic

I guess scispace is as well, but slightly less

[dense vale]

looks nice but nothing existing solutions aren't doing better (e.g perplexity)

[prime robin]

@granite ember I should note that I've recently begun work on upstreaming typst-project into typst-syntax and typst-kit, with more lax manifest parsing to avoid making tools which need the manifest unusable in the presence of a typo

[granite ember]

Okay thank you, I'll definitly check on that later 🙏

[sullen pivot]

What is typst project?

[granite ember]

It's a crate containing the equivalent of the typst manifest into rust (and some functions too)

[flat bane]

• PR introducing the release workflow and bringing up the issue of portability of bash: https://github.com/typst-community/typst-package-template/pull/11
• discussing getting rid of .typstignore: #1194684809906237500 message
  I thought there were more threads of discussion, but I think those contain basically everything that was discussed

[granite ember]

• I see where utpm can be used, with a bit of configuration we can get rid of bash and use this action in every environment
• Okay I get it but getting rid of it I don't know. I always liked to have a .[something]ignore because it's really easy to use and implement (see crate ignore_files). And if you don't want to configure to much, you can just ln -s .typstignore .gitignore

[flat bane]

if it's a proper ignore file (using the crate) it's not so bad, at least I personally think so. We can surely discuss this.

[prime robin]

rust helper crate with helper stuff for typst projects like a manifest and validators similar to the one in the packager (which I've upstreamed to typst-syntax now) as well as some heuristics to find typst projects which don't have manifests

[granite ember]

Is it https://docs.rs/typst-syntax/0.11.1/ ?

[prime robin]

That would be it, but is only on main so far

Other things like validation of universe specific stuff is optional and stuff liek finding the project root (simpler than in typst-project) will come to typst-kit

[prime robin]

@granite ember how important is manifest validation for utpm? i assume it would be relevant for package preparation

I've opened the typst-kit PR for review, but I left out manifest validation since most downstream tools don't need to know or actively want to ignore if a manifest is invalid

if you think it carries it's weight we can add that to typst-kit before the merge too, but i would have it a little less extensie as it was in typst-project (similar to the project lookup being very simple right now)

let me know what you think

The PR in question: https://github.com/typst/typst/pull/4540

[granite ember]

I'll look tonight, I'm busy rn but yeah it's important because in the future utpm will validate and then publish it directly to typst.
Thanks for adding me in the conversation

[granite ember]

I think it does but yes you don't need to put validation on authors like GitHub imo.

I just need to be valid like we do to validate a manifest in typst/packages

And if utpm needs something specific I can just write my own validator for specific fields

[prime robin]

Well the code is already in the packager and if they share the same code you can hardly release a package with an incorrect manifest

[granite ember]

If you already have it, everything is good to me!

[elfin sparrow]

Whenever I'm making a template, I end up copy pasting the same test document to populate it with elements that I expect to be used (headings, equations, figures, etc)

So I'm considering packaging typical placeholder stuff so it can be more easily imported

But such a package would only be useful for template Devs, so my question is, is it worth it?

[prime robin]

Packaging how?

In the end they need to copy it into their dir

[elfin sparrow]

#include package

[prime robin]

But

[elfin sparrow]

Or import package and place a #placeholder-document idk

[prime robin]

How will this help the end user

They'll likely remove it and type their own stuff

Not knowing how the included doc looked like

[elfin sparrow]

^ targeting devs

[prime robin]

Then I don't know how this would look like

The template dev creates their template directory and imports this special package?

[elfin sparrow]

Just while their making it look how they want, so they don't need to make their own placeholder

For example

https://typst.app/universe/package/graceful-genetics/

I use the same text on most my templates to showcase them

Copy pasting it is annoying especially when you find a math typo on the first page ^^'

[prime robin]

OK I see

[elfin sparrow]

So I was thinking #placeholder.abstract, .authors, .title, .body

Things like that

Maybe a couple key "well used" packages too like codly

[prime robin]

I mean I guess, but they sort of depend on the developer too, maybe you're the only one structuring their templates like that

I haven't looked at it I'm on phone

[elfin sparrow]

I know that's why I asked here 😭😅

[prime robin]

I could look at it uhhh

Tomorrow

And see how much of it is common between our templates

Mine isn't public yet so I can't just share it here

[elfin sparrow]

You don't need to, it's an open discussion, feel free not to :p

[prime robin]

I will

Take a look

Perhaps it's very similar and indeed helpful

I haven't put too much thought into my template document because I have my thesis as a direct e2e test

And other tests for smaller components

[granite ember]

It can be useful at some point but for that we need more people that needs this feature I guess.
Create a somewhat generic template, and so values to be tested can be greatful.

[oblique star]

I got my accounts back :D

[prime robin]

Lovely

[elfin sparrow]

New phone who dis

[oblique star]

💔💔

[prime robin]

@oblique star i vaguely recall you turning off pre releases of development branches but i swear i still get a BUNCH of home page notifs about utpm releases

[oblique star]

I'M SORRY I WILL 🙏

[prime robin]

no worries i figured I'd tell you it's not disabled

[thick talon]

Hey :) for info, there is a bot that was added to the typst/packages repo that will send automatic reviews on PRs to catch most common mistakes with package submissions. It will not fully replace the normal review process but should hopefully make it easier for the Typst team, and allow for a first review to be provided as soon as the package is submitted. However it is still a bit experimental, and can be too strict in my experience (I have used it locally to help me with package reviews recently). If you have remarks/feedback on how to improve it, you can tell me, either by pinging me on here or with an issue.

[prime robin]

Oh that looks lovely, I'm sure some of this could be reused by @oblique star at some point down the line

[oblique star]

I love it! I'll check in details later but I will definitely use it!

[prime robin]

i think right now it's just a binray crate, but it could be made into a library crate

[oblique star]

Yeah I mean I'll reused some part of it or it can be a crate

Btw do you think utpm can be a part of typst? Utpm provide the package manager that typst is missing rn, do you think it's a good idea to integrate it?

[prime robin]

I think it needs some polishing first

[oblique star]

Yes ofc 😭

[prime robin]

but many of it's features are things i would expect to be part of typst eventually yes

package submission will likely not be part of it the way it is right now

before this is added to typst itself, itwill likely get upstream support to directly get typst publish, from source to universe without the intermediate PR and repo

[oblique star]

Yes, it's more like a hack than anything else

[prime robin]

but things like local package management should be part of typst's cli, at least under some debug commands

[oblique star]

Do we have something like a registry written anywhere in a todolist?

[prime robin]

purging and managing local packages, pre loading packages, managing git packages (once officially supported) are all things i think will be added

[prime robin]

I'm not quite following?

[oblique star]

Like npm but for typst

I rephrase it, do we have a package-registry for typst anywhere on the road map of typst?

sorry today isn't my best time to speak english, i'm searching my words all the time

[prime robin]

typst universe is a package registry

it has an index at typst.app/universe/preview/index for the preview namespace

[oblique star]

It's not just a frontend for github?

[prime robin]

nope

the repo is just a frontend for deploying new packages

you can already build a proper package manager which gets package from typst universe

(see also typst-kit PR)

[oblique star]

Ooooh okay so it's just a matter of time

I'll check, thank you!

[prime robin]

eventually I want to PR support for configuring registries so people can host their own

cargo allows this too

yeah it's just that there's no auth based API, so publishing is not a thing yet

not really high priority while the PR based approach works fine

[oblique star]

That could be incredible for organisations

[prime robin]

I wonder how it works now really

[oblique star]

Yeah it's really great to start, there isn't so many package updated everyday

[prime robin]

I think they probably still use universe

[oblique star]

What do you mean?

[prime robin]

typst-on-premises

i think they probably just use typst universe as a registry

[oblique star]

But they have a subscription to have a typst-universe in local with typst-on-premises, isn't it?

[prime robin]

I don't think so, otherwise they'd have to also pull in new packages themselves

[runic moat]

@oblique star it would be great to integrate some utpm functionality in typst itself. At least, being able to take a package dir (or a zip or gzip version of it) and install it into the local namespace is a must IMHO to ease development and non-public package sharing.

[oblique star]

I take note on that! Thanks! And yeah I totally agree, but first I need to finish polishing it 🙏

[runic moat]

Indeed! I'm following the project and you're doing great work these days. I wish I can find some time to contribute someday

[oblique star]

Thank you!! I really appreciate it 🙏

[sullen pivot]

what are you working on @oblique star ?

[oblique star]

A package manager for typst!

https://github.com/Thumuss/utpm

[sullen pivot]

wait so how will remote packages work? is this separate from universe?

[oblique star]

Yes it will and yes it separated!

It's already working btw

In the future I'll add a command to publish directly to typst

(check PR if you want, I've written (not a lot) about what I want and what I do)

And if you have any questions or suggestions, let me know!

[sullen pivot]

only the local part no?

[oblique star]

Both! In the dev branch

[sullen pivot]

oh okay, I was just looking at the readme

[oblique star]

Yeah it's not really updated for now 😭😭

[sullen pivot]

is this something that could be incorporated into the typst cli itself in the future?

[oblique star]

I hope so!

[sullen pivot]

I guess having this as a separate testing ground first is a good thing 🙂

to figure out the design

[oblique star]

It will take at least 3 months for me to have a consistent tool polished. In the future it can be interesting!

[oblique star]

Yes that's the biggest issue here, I want something simple, with configurability and intuitive (idk if it's english).

I'm trying subcommands to see if it leads to a simpler usage of it

[sullen pivot]

One thing to keep in mind is that many people using typst won't be actual programmers

Though I guess someone could create a GUI on top of this 🙂

[oblique star]

Yes and I need them to test my program but for now, if it works it's good 🙏

[prime robin]

typst-test now has matrix testing for windows and ubuntu and an mdbook with 2 chapters which is deployed to gh-pages (https://tingerrr.github.io/typst-test/index.html) 🎉

Already found a typo in it 💀

the test do NOT pass

[elfin sparrow]

If you can make issues on the GitHub for things you'd like people to look at making a PR for, then I can check it every now and then and help where I can 🙂

[oblique star]

Sure! I already have an idea 😭

[oblique star]

Okay I've disable pre-releases 🙏

[oblique star]

From now on, i'll discuss utpm on #1266702763539304461 ! If there is something to transfert from here, ping me!

[flat bane]

Depositing this here: #1268987926121812009 message

We should definitely include the "rule in a loop" pattern in some community document.

[prime robin]

the typstnomicon would be a good fit

actually

i think it already has this

well if it does then i can't find it https://sitandr.github.io/typst-examples-book/book/about.html

[daring nymph]

What's the best way of tools (LSP) recognizing packages using tidy as documentation framework?

[lost void]

Hello everyone,

I am the current maintainer of Glossarium. I started Glossarium based on @Dherse work because I needed a glossary with similar features to those available in LaTeX. It served me well, especially during the creation of my master's thesis.

However, I am now working full-time for a fintech scale-up and no longer have the time to maintain Glossarium. I plan to archive the repository soon, and I would like to transfer the "ownership" of the name within the Typst Package repository. I understand that it's not truly my property, but I believe it would be beneficial for this transfer to happen in an orderly fashion. It would also be ideal if Glossarium's development could continue in a unified manner, rather than through competing forks.

In my humble opinion, one of the best places for the future of Glossarium would be the Typst-Community organization on GitHub.

[dense vale]

i'll send over an invite and you can transfer it over. However, i should note unless someone has interest in taking over maintainership, it'll probably be unmaintained for awhile

invite sent

[dense vale]

@lost void_ops forgot to reply_

[prime robin]

How's the pulse of the project

Does it get lots of requests?

Because if it's fairly low profile in terms of new requests, then I wouldn't mind doing passive maintenance similar to valkyrie

I mainly help reviewing on valkyrie and doing patch releases when necessary

[lost void]

There is some features request already waiting (6 or 7 I think) and there is not a lot of activity since most features you would want in a glossary are already implemented

[prime robin]

hmm

these don't seem to drastic

[lost void]

it's now transfered

[ornate condor]

huwaireb

[typst-community/glossarium] New collaborator added: slashformotion

[dense vale]

i've given you the highest possible permission on the repository.

[lost void]

thanks

[elfin sparrow]

@prime robin could typst-test measure and store timings, and fail above some threshold increase in compile time per test if set?

[prime robin]

It could, it's something I've considered, but not yet implemented

I already track the times on main but I don't have any saving/loading yet

[elfin sparrow]

nice 🙂

[ornate condor]

quachpas

[org] New discussion #11: Maintenance glossarium

Hello!
I've seen the discussion on Discord about about @slashformotion looking for maintainers for glossarium, albeit too late. I have contributed previously to glossarium and have a WIP PR pending for Typst v0.12.0. I was waiting for slash's input, but now I realize he might not answer at all!
Who should I discuss the PR with? Also, please know that if you do need an active mai...

[dense vale]

@errant pulsar

@slash did he leave?

[dense vale]

i've replied to the discussion

[errant pulsar]

I'll look at it later, thanks!

[ornate condor]

quachpas

[typst-community/glossarium] New collaborator added: quachpas

[ornate condor]

quachpas

[glossarium] New discussion #61: Please post on https://forum.typst.app/ instead for user questions. Feature requests, bugs, etc. belong to issues.

Don't hesitate to read this introductory post on how to ask questions first! https://forum.typst.app/t/how-to-post-in-the-questions-category/11

I am watching the glossarium tag, so don't forget to use it :) Otherwise, I might not notice your question.

Cheers!

JakeMomo

[glossarium] New discussion #62: How to share a glossary among multiple files

I'm writing a document with each chapter having a dedicated file. I tried sharing the glossary by writing the #print-glossary in a dedicated file and including it everywhere, but it doesn't work : the terms are not found by typst. Is there a way to do this ?

[ornate condor]

quachpas

[typst-community/glossarium] New release published: v0.4.2

[errant pulsar]

Hello, please be aware that there are breaking changes in there for those of you who upgrade to typst v0.12.0

[sullen pivot]

Packages on universe should probably not be updated before 0.12 is released if they don't work in 0.11.1

But maybe I misunderstood what you meant

[errant pulsar]

It still works on 0.11.1

The API only changes for 0.12.0 users

[sullen pivot]

Ok, I see

[errant pulsar]

I'm not sure if it answers your worries?

If you think it should be done another way, please share your thoughts with me! I'll be glad to listen

[sullen pivot]

It does!

[ornate condor]

quachpas

[typst-community/glossarium] New release published: v0.5.0

[ornate condor]

gerob311

[glossarium] New discussion #71: A way to query glossary references separately to web links

It's great that there's an example on how to style the links generated by this package.

#show link: set text(fill: blue)

However, I'd like to be able to style links to the glossary, differently to URLs. Do glossary links have a label on them that can be used to create a more specific show command? Something like

#show link.where(label: ): it => smallcaps(it)

Where `` is a label attached to every glossary reference.

[prime robin]

If someone is interested in contributing

[ornate condor]

quachpas

[typst-community/glossarium] New release published: v0.5.1

[obtuse solar]

Hey there,
not sure if this is the right place and if i understood the purpose of typst-community correctly. But i created the package https://github.com/jomaway/typst-linguify some time ago, as a side project for another package of mine. But i currently don't have the capacity to further maintain it. So i wondered if this is something which is in your eyes worth keeping alive as a community project.

There hasn't been alot of changes in the last months and probably don't have to be until some typst update makes this necessary.

[flat bane]

that's exactly one of the community's purposes 😉

I have used (and recommended) linguify! I could imagine taking over the maintainer role under the community umbrella to apply necessary updates 🙂

[obtuse solar]

That's good to know 🙂

How would be the further steps to proceed?

[prime robin]

I believe there's a transfer template on the org issue tracker

[flat bane]

as I had to look a bit myself: https://github.com/orgs/typst-community/discussions/new/choose this is where you can initiate that.

[obtuse solar]

Thanks so far. I will have a look tomorrow.

[ornate condor]

jomaway

[org] New discussion #12: Transfer Request for linguify to typst-community

Project Name

linguify

Initial Author(s)

jomaway

Repository URL

https://github.com/jomaway/typst-linguify

Status

Unmaintained

Description

Linguify is a package to load strings for different languages easily. The translations can be stored in a seperate toml file and is applied with the linguify() function. There are currently different workflows depending on package or template usage.

License

MIT

[ornate condor]

typst-community

[typst-community/linguify] New collaborator added: jomaway

[elfin sparrow]

would I be ok transfering to the community org those templates which I packaged from laur?

(don't feel like they are mine in particular so its very unlikely that I'll personally make any creative updates, and generally not a whole lot more other than keeping them working with the current typst version)

(can also come up with better names for them, if wanted)

[prime robin]

Sure I think that's fine

[elfin sparrow]

might be a weekend job

[oblique star]

I'll potentially transfer (if it's ok) like truthfy, my uni year is really wild and I don't have time 😔
If that's ok i'll contribute to it sometimes when I'm free

I'm saying that because I saw peoples using it but they reported complex issues...

[dense vale]

it's ok, are you part of the org?

[dense vale]

yes, feel free

[flat bane]

@obtuse solar could you add me as a collaborator on linguify? thanks!

[oblique star]

I'm not!

Sorry I'm a bit late

[dense vale]

gimme GitHub @

[oblique star]

Thumuss

[dense vale]

sent

[oblique star]

Thank you!

[runic moat]

Just in case you already don't know this, resvg has new maintainers https://linebender.org/blog/tmix-10/

[dense vale]

vello wasnt harmed right? 😭

ok only resvgs author can't continue unfortunately

[tough crown]

Hello everyone,
I want to share this update-in-progress on documentation for Typst packages with you
https://github.com/Mc-Zen/tidy/issues/32

[prime robin]

Was about to post this here haha

[tough crown]

Yeah I tagged you there haha

[obtuse solar]

sorry i have been travelling and did not read your message. I canˋt see the settings page since i transvered to typst community. So i donˋt know how to add you as a collaborator.

[dense vale]

they did not..

😮‍💨

yeah they literally removed the maintain, admin perms, put them behind enterprise

i dont get it? its there

@obtuse solar ill remove u and add u back

[ornate condor]

huwaireb

[typst-community/linguify] New collaborator added: jomaway

[dense vale]

where is it even??

...

🗿

[elfin sparrow]

Wonder if GitHub would be open to a free enterprise membership given it's a community interest "company" rather than one that makes money

[dense vale]

probably needs to be registered as a non-profit

i doubt they charge non-profits

lmao nvm they do

@obtuse solar try to add him now

[flat bane]

isn't it just a matter of scrolling in the list of roles? it is in the orgs I'm an admin of...

[dense vale]

there is no indication of scroll 😭 i figured that out after removing the advertising

[prime robin]

lol

[flat bane]

I remember feeling similarly confused tbh 😂

[sullen pivot]

Non profit doesn't mean that money doesn't change hands

[dense vale]

😂

wonder what non-profit can justify github enterprise 🗿

[prime robin]

plenty i thinik if they're large enough

they still make money, it's just used for things like these

[errant pulsar]

github is overrated, switch to codeberg 🤡

[elfin sparrow]

Absolutely loathe the clown face emoji

[prime robin]

codeberg can be god all you want, but github is the norm for git the same way discord is the norm for community servers

not saying that's good, but it is how it is

[obtuse solar]

i have the settings tab now but still no option to add someone.

[dense vale]

interesting

[dense vale]

here direct url, can u try?

https://github.com/typst-community/linguify/settings/access

ops should've given u admin, now should work

[ornate condor]

jomaway

[typst-community/linguify] New collaborator added: SillyFreak

[obtuse solar]

did work

[flat bane]

thank you all 🙂

[errant pulsar]

I always add a clown face to offensively simplified statements 🤣

[elfin sparrow]

It's the people who aren't being ironic that get me :p

[dense vale]

not codeberg but after seeing, whole heartedly agree

nothing beats github in terms of UI except maybe https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

yes i care about UI more than anything, if that wasn't obvious

but lack of search and syntax support is hard-coded poorly 🗿

front page https://radicle.xyz/

[errant pulsar]

Honestly, forgejo/codeberg is incredibly better than it was a few years ago, they made a lot of progress
If they wanted to look more like GitHub, they just have to adopt rounded Material themes, and subtle shadows 🤷‍♀️

[errant pulsar]

Radicle is so niche, but definitely looks pretty

[indigo badger]

I loved the font and wanted to use it for my computer and then I realised I already do

[dense vale]

isn't that iosevka? the ligatures are odd (i use it if so 😂)

[solid umbra]

seems to be jetbrains mono

[dense vale]

huh looks oddly similar

nah thats iosevka no way

🗿

[solid umbra]

look at the j

[dense vale]

looks very similar other than the j

[solid umbra]

it's similar in a way

for sure

though iosevka looks thinner to me

anyway i use maple mono 😎

the Gleam community got me into it

now i cannot go back

😂

[dense vale]

that is very smoooooooooooooooooooooooooooooooooootth

time to switch fonts?

[solid umbra]

it's never too late...

[sullen pivot]

I really dislike the cursive italic. Thankfully there is a font feature to turn it off

[solid umbra]

it's the icing in the cake though

:<

[sullen pivot]

Bad icing 😂

[rough pulsar]

Yeah same

Didn't know it can be disabled though

I currently use Berkeley Mono

[sullen pivot]

https://github.com/microsoft/cascadia-code

It's controlled by ss01

[rough pulsar]

@solid umbra used Maple Mono though?

[sullen pivot]

Is that related to maple the software?

[rough pulsar]

Uh, it's just the name of the font: https://github.com/subframe7536/maple-font

[sullen pivot]

Ok I thought maybe it was the default in Maple or something

[solid umbra]

kek

what math brain does to a human

[solid umbra]

it seems maple mono is gonna be releasing a new version soon which will have the same thing i think

based on https://github.com/subframe7536/maple-font/issues/108#issuecomment-1962408737

one of the few comments in english there :p

[indigo badger]

I meant the sans serif

[dense vale]

oh

[indigo badger]

I use julia mono

[tacit nymph]

very based choice

[oblique star]

I'm sorry to bother you @prime robin but have you publish typst-project? If not, do you have something that have a parser for typst.toml? I'm trying to publish utpm but typst-project seems to not be published on crates.io

[prime robin]

you can use typst-kit and typst-syntax for that

those do not validate though

i left it unpublished beacuse i simply upstreamed most of what i think is sensible

[oblique star]

Thanks I found it!

I'm seeing what I need to do, I'll pass it for now, I don't feel the courage in me

[daring nymph]

According to discussion, typst-grammar want to move to typst-community org.

[dense vale]

feel free to move it at any time, i've invited you a while back to the organization

oh yours is a fork? which one are we moving michidk or yours? i'll invite michidk in eithercase

[jagged ridge]

Ah, I wondered where the discussion was going on 😅

Thanks for inviting me.

I guess it does not really matter which repo we are moving.
I would actually suggest that the community forks the repo, as we need to have both repositories available at the same time (at least until we merged our PR into github-linguist).

[dense vale]

do you plan to have github linguist point to your repository, myriad's repository or the one in typst-community?

[jagged ridge]

the one in typst-community

[prime robin]

Would somebody be interested in taking over maintenance of the subpar package?

Right now, it's fairly janky mainly because I wanted it to be show-rule free, i.e. the user can simply call the functions without any setup required. This has the downside of requiring multiple hacks within typst to get numberings and such right and it blocks features such as aligned captions in sub figure grids. I think if someone put their mind to it they could design a nice package with good looks and similarily easy usage, but I don't have the time for it and would rather work on typst-test to fix it's long standing issues.

I don't think any of the current code has to be retained it could be designed from scratch but I'm willing to handover the name if someon is willing to design a better package for sub figures (or better yet add support within typst itself).

EDIT: as noted below, here's the forum post.

[prime robin]

Hey guys, I'm looking to transfer the typst-test to typst-community under a new name soon when I reach the 0.1.0 milestone. I'd appreciate if someone else who's active enough would take joint ownership of the project with me to increase the bus factor. I was recently reminded of the bus-factor when I saw typst-lsp mentioned.

I want to make clear that whoever joins doesn't need to help maintain it for the moment if they don't want to or can't, but they would get all permissions necessary to transfer the project to someone who can and wants to if I become unresponsive.

I wonder if we should introduce something like rust's rust-bus maintainer group, but, considering that this very group went defunct before any of the crates it has ownership of needed it, perhaps we should keep it at joint ownership.

Also, bump on the previous post, I'll make a community post for it too and if nobody wants to maintain it I'll archive it instead, I guess.

[ornate condor]

quachpas

[typst-community/glossarium] New release published: v0.5.2

quachpas

[typst-community/glossarium] New release published: v0.5.2

[flat bane]

Could someone give me write permissions on the typst-package-template repo? I think it would be sensible for me to be able to merge PRs.

(also, what's your opinion on self-merges? should I wait for someone else to merge my PRs (once I have another one), or is that not necessary?)

[prime robin]

if you're the primary maintainer then you should have full write access and I don't think you should wait for anyone to approve it unless you're actively looking for input

I generally create PRs for anything more substantial than a typo fix or small correction where running tests is a good idea, not sure how this would apply to something like a template repo

[flat bane]

James and I are currently the biggest contributors, and I would consider myself kind of a maintainer (even though I have not e.g. realized my plans of replacing the scripts with a separate executable; I've kinda stumbled into analysis paralysis there, and life also got in the way).

I recall that there was a conversation with @elfin sparrow that he didn't mind if I added stuff to the template that wasn't originally his vision, but I can't find it.

[prime robin]

Regarding the executable it seems somebody had a similar idea with typship

@tropic field it was i believe

I guess if James gives a confirmation in here then @dense vale could elevate your privileges on the repo

[flat bane]

yeah it's on my list 😅

[prime robin]

Good list, thanks for reminding me of graphite, I keep forgetting to give it a good try

[flat bane]

btw @prime robin I just tried to install tytanic v0.1.1 and got the following:

$ cargo binstall [email protected]
 WARN Failed to read git credential file /home/clemens/.git-credentials err=Os { code: 2, kind: NotFound, message: "No such file or directory" }
 INFO resolve: Resolving package: 'tytanic@=0.1.1'
ERROR Fatal error:
  × For crate tytanic: Failed to parse cargo manifest: TOML parse error at line 38, column 11
  │    |
  │ 38 | pkg-fmt = "tar.xz"
  │    |           ^^^^^^^^
  │ unknown variant `tar.xz`, expected one of `tar`, `tbz2`, `tgz`, `txz`, `tzstd`, `zip`, `bin`

I just updated binstall so I doubt it's a problem on my end; probably just mistyped out of habit?

[ornate condor]

huwaireb

[typst-community/typst-package-template] New collaborator added: SillyFreak

[dense vale]

i've added you as a maintainer

[prime robin]

Hmm, that's on me I figured it would understand this, it documents the field but doesn't document the values it accepts

That's annoying this means binstall won't work with those versions

You can override the archive format

I assume you need to pass txz then

[flat bane]

I'll try after dinner

[flat bane]

ok, that also doesn't seem to work. I assume because it fails during reading the manifest, before it checks whether to override the manifest value.

cargo install works though 😛

[prime robin]

Unlucky

[tacit nymph]

Hey @prime robin I know you're looking for a new maintainer for subpar but until then, I would like to inform you that the package is broken in v0.13-rc1. As in, just calling #subpar.grid() leads to Expected integer, float, decimal, version, bytes, label, type, or string, found function. I assume this has to do with "new" type checks and is maybe somewhere in here https://github.com/tingerrr/subpar/blob/main/src/lib.typ#L231-L239. But until then, the package is completely broken for now.

Same with drafting by @lilac knot btw but I filed an issue there, that old string type check is easier to replace.

[prime robin]

Could you open an issue about that?

[tacit nymph]

Sure

https://github.com/tingerrr/subpar/issues/24

[prime robin]

ty!

[errant pulsar]

@dreamy kite, are you planning on maintaining metro further?

[dreamy kite]

I'm on a project hiatus until end of May, but I'm aware Metro will be broken in 0.13. I'll probably make an exception to fix it

[errant pulsar]

#let q(l) = {
  if query(l).len() > 0 {
    true
  } else {
    false
  }
}
#table(
  columns: 2,
  "body", "caption",
  {
    show figure: f => align(start, f.body)
    figure(
      supplement: "",
      numbering: none,
      kind: "glossarium",
      caption: "",
      context if q(<lorem>) { [Lorem] },
    )
    figure(
      supplement: "",
      numbering: none,
      kind: "glossarium",
      caption: "",
      context if q(<ipsum>) { [Ipsum] },
    )
    figure(
      supplement: "",
      numbering: none,
      kind: "glossarium",
      caption: "",
      context if q(<dolor>) { [Dolor] },
    )
  },
  {
    show figure: f => align(start, f.caption)
    figure(
      supplement: "",
      numbering: none,
      kind: "glossarium",
      caption: context if q(<lorem>) { [Lorem] },
    )[]
    figure(
      supplement: "",
      numbering: none,
      kind: "glossarium",
      caption: context if q(<ipsum>) { [Ipsum] },
    )[]
    figure(
      supplement: "",
      numbering: none,
      kind: "glossarium",
      caption: context if q(<dolor>) { [Dolor] },
    )[]
  },
)

Does anyone remember a PR changing this behaviour? It's kind of funky that context expressions don't reduce when in caption, but do in body

not even sure that's a bug... or is it?

[hearty perch]

I think this could also be because captions are now blocks, so even an empty context will now create a new block. This was part of the semantic paragraphs PR

[errant pulsar]

ah that should be it

I should have looked at that PR more in detail uurgh

[ornate condor]

yusancky

[typst-community/setup-typst] New release published: v4.0.0

quachpas

[typst-community/glossarium] New release published: v0.5.3

[prime robin]

Is the author of the setup-typst GitHub action in here?

[ornate condor]

alex289

[glossarium] New discussion #105: Display entries in a grid

Hi there, I was wondering if it was possible to print the entries in a grid like way. From the advanved documentation I didnt get it working.

For example I currently have this setup and want to make all explanations start at the red line.

The code I used to display it like this is:

#import "@preview/glossarium:0.5.2": register-glossary, print-glossary, gls, glspl
#import "../acronyms.typ": acro...

[prime robin]

@flat bane that's so funny, I was looking at the template CI yesterday and was wondering if the apt cache was even needed at all. I figured no and wanted to look into the binstall action too.

[flat bane]

good timing 😛

[prime robin]

@flat bane I've got a question about the release workflow, James is using this for valkyrie, he's MIA right now and I'm preparing a release so that it stays usable for 0.13, if i push a tag will it create the PR from his or my account?

looking a little harder seems to have cleard it up

it'll create a branch and i can create the PR from there

hmm well but it'll show with my email then and I don't think i cna PR from a repo i dont' have write access too, but i can't change the secrets

well that sucks

[flat bane]

It uses the configured token secret for access, and the name and email from the last (tagged) commit for creating the release commit.

Who has write access to typst-community/packages? It should be possible to add you as a contributor there, no?

[ornate condor]

tingerrr

[typst-community/valkyrie] New release published: v0.2.2

[prime robin]

i figured I'll just do it manually, i disabled the release workflow for that tag

[prime robin]

Yeah I mean, won't that be James' token then?

Can't use his token to create commits with my email and user name

well i probably can, but it doesn't feel right lol

[flat bane]

i guess 😛 I don't think we have an answer to "what token should be used to commit automatically from a community package" yet...
on the other hand, that this token would be effectively used by other people is just another reason why the scope of the token is limited. it doesn't feel massively wrong to use it to me.

[dense vale]

discord banned in china afaik, so no

@prime iris is co-maintaining it i guess?

[prime robin]

damn

💀

[flat bane]

I'm in the same situation now regarding the linguify package, except that since @obtuse solar didn't use the template, the repo has no token configured (and I don't have access to the packages repo so I couldn't create one myself) 😛

I think the cleanest way would be for one of the org admins to create an org-scope secret (here). that way all repos owned by the community could use it, without arbitrary maintainers needing access to the packages repo or needing to create personal tokens.

[prime robin]

cc: @dense vale

if push comes to shove you cna still create a release manually right?

[dense vale]

was the packages repo successfully used to automatically open PRs? i thought there was an issue?

[prime robin]

Well not for me because I don't have push access

[flat bane]

yes, or I can point the action to my personal packages fork, but that's feels like a hack 😛

[flat bane]

hmm, I'm actually not sure what permissions one needs so that GH shows the "there's new commits on <fork>, you can create a PR" banner 🤔

but that's basically what would be needed. the CI only creates a branch on community/packages, and the PR would be created manually by a maintainer, who needs to see that banner for it to be convenient.

[prime robin]

I recently changed a few things about my workflow with packages especially with regards to compiling and updating manuals and I'm wondering if these workflows could be a good fit for typst-package-template. They're a little opinionated, which is why I don't want to open a PR yet. I'll lay out my points here and you can tell me if you think it's worth adding to the template. @flat bane

I generally always put assets like fonts and images use in examples or manuals or even the package itself in a top level asset directory, and it always irked me that the manual is not there, one one hand it should be in docs/doc, but on the other hand the assets are all those files which go into the repository as a persisted non-source document.

So I figured I'd actually ignore the immediate output of all of them by adding a gitignored out directory for each individual asset. Then I moved them all into assets (apart from the manual) and had added Justfile recipes which generate/watch items and a dedicated one for updating them (i.e. moving from the out directory to the assets directory.

The benefits are that each asset now lives in one place and isn't overridden every time you touch your manual, only once you run update-* and because generating them and updating them are different recipes, the sometimes annoyingly slow operation of optimizing images with oxipng is now only done when an asset is updated.

An example of this is on this branch of hydra: https://github.com/tingerrr/hydra/pull/14

I think this also allows putting each individual asset into it's own Justfile module, but I didn't do that for now.

It irks me a little that just went with a syntax so close to that of make, i always lose track of what I'm looking at in a larger Justfile

Completely separate: I want to try out typship and I'll make a PR for it to support .typstignore files, as a heads up. Though I hope that in the future there won't be a need for it when a theoretical typst package manager simply uses exclude, but this still doesn't quite handle the case of files that should be on the registry, but not added to the package on download. See https://github.com/sjfhsjfh/typship/pull/9.

[flat bane]

I had to think a bit to understand everything you mean, so I'll quickly lay it out just to be sure. iiuc you're talking about the following things

• (there's source files that go into the actual Typst package)
• there's assets, which to me means non-source files that are the input to building some artifact (that's what you mean by "files which go into the repository as a persisted non-source document", right?)
• there's artifacts, which are things that are built from sources and assets, such as manuals, examples, thumbnail or similar images (but I think in your description you also included them in assets)
• and there's intermediates such as yet-to-be-optimized PNGs

And you're looking for a unified way to handle the outputs (artifacts and intermediates) of different sorts, right?

I'm not sure about the naming; as you can see I don't really agree that e.g. the manual is an asset, but maybe that's just me. I get the goal though. (And I've also gone a bit into the opinionated direction with adding thumbnail.typ next to the manual, that's also something one could disagree about.)

The benefits are that each asset now lives in one place and isn't overridden every time you touch your manual

You mean that you can compare an old and new PDF of the manual? Yeah, I think I have sometimes had to rename the old manual if I had to do visual comparisons, so that's a nice benefit!

fwiw, I also have a few customizations I keep on top of the community template; mostly adapting metadata, simplifying the README and adding a template for the manual: https://github.com/SillyFreak/typst-package-template/commits/main/
There's also a stub for a gallery, which overlaps with your intent but is not as comprehensive.

[flat bane]

I think my thoughts on whether to include this are around two competing factors:

• does including it force/suggest complexity that package authors may not need?
• does including it simplify conforming to best practices that are hard to discover or implement, and thus would not be taken up by package authors?

For example the recent addition of the thumbnail: it's opinionated to have one, but I think 1) having one at all makes most packages more attractive, which is in the authors' interest and thus a best practice and 2) adding a dark mode compatible thumbnail is not obvious, so authors who would add a thumbnail anyway will probably arrive at a better solution with the template providing it.

I think promoting the use of oxipng would fit in this regard, but I'm not sure about the assets dir as a whole; that's complexity that is motivated more by being opinionated than promoting best practice.

(and I know that I'm obviously biased towards my own additions, so please let me know if that seems like an unfair assessment)

[flat bane]

I'll comment on the issue 🙂

[prime robin]

Not quite, I'll lay out some points I miscommunicated when I'm home

[tacit nymph]

@lilac knot hey if you can find the time, could you change the drafting readme in the 0.2.2 PR to match the import versions? https://github.com/typst/packages/pull/1678#issuecomment-2640795503

i think this is the current blocker for this version to get merged

[oblique star]

I hesitate to put utpm on the organization, I don't have so much time to work on it

Do you think it's a good idea? And do you want it?

[runic moat]

I think it's a great idea. It deserves being further developed and eventually integrate the most mature parts into typst itself or a standalone package cli.

[prime robin]

If you don't have much time to work on it perhaps it is better to upstream some stuff into typship instead? For now it seems actively maintained and splintering the ecosystem early is rarely a good idea.

[oblique star]

Yes, I didn't search a lot on it but for what I saw typship contains everything that utpm has

And ship it will requires time unfortunately

• it could be selfish but I don't have many projects with 60 stars and for my portfolio it's important

[prime robin]

it's up to you of course, friendly competition is also good for the ecosystem :)

But i generally prefer working together on things, sharing ideas and not wasting energy re-inventing the wheel

[sullen pivot]

Wouldn't having a project good enough to be turned into a community project look good on your portfolio as well?

[oblique star]

Yes! For that it's good! But if I ship it directly to typship I would "lost" this

[prime robin]

Active contribution to a project not on your account also looks good :)

Regardless you guys could atthe very least share ideas

I think json output is very helpful which typship doesn't have! I stole that idea from utpm for tytanic for example

[oblique star]

You're right! Thanks, I'll think about it and I'll come back later

[prime robin]

And you're looking for a unified way to handle the outputs (artifacts and intermediates) of different sorts, right?
Correct!

You mean that you can compare an old and new PDF of the manual? Yeah, I think I have sometimes had to rename the old manual if I had to do visual comparisons, so that's a nice benefit!
Not just that, this extends to other assets and it has other benefits too, like avoiding accidental updates from just checking that something still compiles but will never create the same binary output (manual which includes a timestamp).

For me it was always annoying that just testing that the manual still compiles generates a new one which is different to the old manual because it has the timestamp in it (and it has to because the date is on the title page), this alleviates the problem. As I already alluded to, for PNG artifacts/assets this means one can keep the optimization step purely within the update-* recipe, making iteration on such assets faster.

I currently do it like so:

├ assets/
│ ├ images
│ │ └ thumbnail
│ │   ├ out/thumbnail.svg <-- ignored
│ │   └ thumbnail.typ
│ │
│ ├ manual.pdf <-- not ignored
│ └ thumbnail.svg <-- not ignored
│
├ docs
│ ├ out/manual.pdf <-- ignored
│ └ manual.typ
│
├ src
│ └ ...
│
└ tests
  └ ...

Here, updating the manual is a conscious process, you run just generate-manual or just watch-manual to generate docs/out/manual.pdf, this is ignored/not persisted in the repository. I went with an out directory because in hydra I also have assets which generate multiple individual pages and this keeps it a little cleaner to navigate and clean up. For a manual or the thumbnail it wouldn't matter.

But I'm thinking it may make the most sense like this:

├ assets/
│ ├ images
│ │ ├ thumbnail
│ │ │ ├ thumbnail.svg <-- temporary, i.e. ignored
│ │ │ └ thumbnail.typ
│ │ └ thumbnail.svg <-- persisted, i.e not ignored
│ │
│ ├ fonts
│ │ └ ...
│ │
│ └ manual.pdf <-- persisted, i.e not ignored
│
├ docs
│ ├ manual.pdf <-- temporary, i.e. ignored
│ └ manual.typ
│
├ src
│ └ ...
│
└ tests
  └ ...

Docs being a top level item makes sense, it could be fairly complicated and have supplementary scripts and such, but in the end it is reduced to a single PDF which is consciously updated. Other assets like fonts are all in their own directory like assets/fonts/LM Sans/..., images are in assets/images/..., if they are regular images they're just in there as is, if they are generated from Typst or Python or whatever they get their own directory as shown above.

Hope that this makes more sense

Some of the files i currently have in assets/images are examples for the manual, I'd rather have these not be assets at all but that's blocked on embedding typst documents without them interfering the introspection of the outer document, so I gotta compile them in advance and have them in seperate files.

I think the benefit is that the layout is consistent and it's very clear when a file is part of the repo and when it is not, for blobs that is.

[prime robin]

For example the recent addition of the thumbnail: it's opinionated to have one, but I think 1) having one at all makes most packages more attractive, which is in the authors' interest and thus a best practice and 2) adding a dark mode compatible thumbnail is not obvious, so authors who would add a thumbnail anyway will probably arrive at a better solution with the template providing it.
Yeah I definitely agree, I think having this in as is in the repository template is good.

I think promoting the use of oxipng would fit in this regard, but I'm not sure about the assets dir as a whole; that's complexity that is motivated more by being opinionated than promoting best practice.
I believe the exact structure is not that important, but the separation of temporaries and "live" assets/artifacts. I chose came to the structure naturally by trying to keep the place of blobs consistent.

forgot to reply to the first message

[flat bane]

(and it has to because the date is on the title page)
I always put the release date into the manual on purpose 😛 but that's of course also a pretty opinionated decision.

But I'm thinking it may make the most sense like this:
fwiw, I like this one better. It's a tiny bit flatter, and it fits standalone and derived assets next to each other more naturally imo.

I believe the exact structure is not that important
For adding to the template we have to come to a conclusion of course 😛

The only thing that I definitely want to have more thoughts on is this: are all "assets" excluded, or does the assets directory (potentially) contain files that would be used by the package? I feel like a structural separation between these two makes sense, but it also seems contrary to achieving a consistent layout..

Oh, something else @prime robin, you have tried out typship a bit, right? would it already be an option for retiring the template's shell scripts, or is there something missing still?

[prime robin]

I always put the release date into the manual on purpose 😛 but that's of course also a pretty opinionated decision.
Well yes, so do I, it just means that without the separation checking if the manual compiles would also update the file in the working copy which would then show it as changed because of the differing timestamp.

The only thing that I definitely want to have more thoughts on is this: are all "assets" excluded, or does the assets directory (potentially) contain files that would be used by the package? I feel like a structural separation between these two makes sense, but it also seems contrary to achieving a consistent layout..
Only those which aren't used in source, perhaps these should be different directories, but then one might ask what the name should be for either of them. Maybe assets for use in the package code and artifacts for used only on the repository?

I think this is one of those problems where a cnsistent conventional structure supported by Typst itself could be beneficial, cargo will automatically include the source files, README.md, LICENSE and then whatever else is in package.include. In Typst it's all except what's inside package.exclude and I'm not sure that's a better at the moment.

Oh, something else @prime robin, you have tried out typship a bit, right? would it already be an option for retiring the template's shell scripts, or is there something missing still?
Nope, not yet, I plan to for the next hydra release, but I am still waiting for some features on mantys and judging by the radio silence on the author's part it may not happen anytime soon, so I may skip that.

[sullen pivot]

@prime robin dropping blog post after blog post

[prime robin]

Yeah I've got dead time at work (I don't)

[ornate condor]

jeremyforan

[glossarium] New discussion #108: Including glossarium in a package/theme

Hello,

I am making a theme for myself that I plan to reuse on multiple projects. I would like to include a a glossary but not sure the proper way to do that.

assuming I have a file gloss.typ

#import "@preview/glossarium:0.5.1": make-glossary, register-glossary, print-glossary, gls, glspl
#show: make-glossary
#let entry-list = (
  (
    key: "ci-cd",
    short: "CI/CD",
    long: "Continuous Integration and Continuous Delivery",
    description: "A set of practices that...

[errant pulsar]

can we disable discussions for glossarium specifically? I'd prefer users to post on the forum instead 😦

or is that a group setting?

[ornate condor]

quachpas

[glossarium] Discussion #105 marked answered: Display entries in a grid

Hello @alex289, this is rather similar to
https://forum.typst.app/t/how-to-fully-control-visualization-of-a-glossary-in-glossarium/1694
My best advice is to adapt the code to your needs
If you find yourself with technical issues, I'll try my best to help

In any case, for grid-like output, it's best to override user-print-glossary, because you can control entries and groups, that is you write the loop to generate the whole glossary

[flat bane]

I'd be interested in your opinions on supporting and explicitly using prereleases in the template's testing CI action: https://github.com/typst-community/typst-package-template/pull/31

Basically the options are

• don't merge this
• remove 0.13.0-rc1 from the matrix, but prepare the action for installing Tytanic prereleases
• merge as-is, i.e. referencing the Typst and Tytanic prereleases (they would be replaced with the releases once they're out)

[prime robin]

Are you sure about the lack of prerelease support? or was the because i didn't publish the crate in time?

for me it doesn't fail when i run the command you used

Maybe the action uses an older version of binstall which didn't support this?

[flat bane]

whoops, the binstall error I included was just timing. but the action definitely doesn't support it:

Error: install-action v2 does not support semver pre-release and build-metadata: '0.2.0-rc1'; if you need these supports again, please submit an issue at https://github.com/taiki-e/install-action

[prime robin]

Well maybe requesting this is just simpler than trying to use the sluggish cargo install

I also thought about forking setup-typst which is essentially the same as cargo binstall but only for typst

But i don't ever use node so I'd first have to understand what is going on there

[flat bane]

yeah, you're probably right

[prime robin]

can you link the workflow that failed?

[flat bane]

https://github.com/SillyFreak/typst-package-template/actions/runs/13393470506 you can't see the logs but the error output is shown

[flat bane]

(I'll create an issue) -- https://github.com/taiki-e/install-action/issues/858

[prime robin]

400 crates for typship is crazy

I wanted to try out typship for this hydra release and when i generated the fine grained access token on GitHub it didn't actually show me the token lol

oh man helix really needs it's own ignore file i just wondered why typship wouldn't add the assets to my release and it was because of the .ignore file

something to be aware of

[prime robin]

I'm waiting until it has spare clone or whatever it was because I'm getting a million CI jobs on my fork running

[ornate condor]

yusancky

[typst-community/setup-typst] New release published: v4.0.1

[ornate condor]

yusancky

[typst-community/setup-typst] New release published: v4.0.2

[prime robin]

does somebody know which kind of features are offered to organizations only on github?

i think merge queues are only available for organizations for example, i wonder what else this extends to, i couldn't really find anything about this

[flat bane]

I know that there are org-wide secrets and that you have more options for permission management (more roles, adding people to teams and then granting access to a whole team, for example), but not much else

[daring nymph]

@rough pulsar @dusky peak typst-ansi-hl and typstfmt could use typst-syntax 0.13.0.

https://github.com/Myriad-Dreamin/tinymist/blob/dc3482594b981066e39549b6d3a4fd1bdc842359/Cargo.lock#L4904-L4919

[[package]]
name = "typstfmt"
version = "0.12.1"
source = "git+https://github.com/Myriad-Dreamin/typstfmt?tag=v0.12.1#c1fd45a4594b916b6e37e3257a69dbcdf25fe339"
dependencies = [
 "confy",
 "globmatch",
 "itertools 0.13.0",
 "lexopt",
 "regex",
 "serde",
 "toml",
 "tracing",
 "typst-syntax 0.12.0", // here!
 "unicode-width 0.2.0",
]

[dusky peak]

Yes, and?

Considering you have forked typstfmt, you can update the version yourself. I might be able to add some commits too soon-ish.

[daring nymph]

there should be some compile error caused typst v0.13 introduces SyntaxKind::MathText. I guess it is not so trivial, at least not only bumping the version in Cargo.toml.

[dusky peak]

hmm

Well, I would have to take a closer look at it, but some other time.

[daring nymph]

Okay, just added them to both of your and my todo-lists, might not cooking them forever.

[rough pulsar]

Agreed

I'll update it today evening

[rough pulsar]

I just updated it

[ornate condor]

quachpas

[typst-community/glossarium] New release published: v0.5.4

[ornate condor]

Ants-Aare

[org] New discussion #13: Open source community to host and maintain typst chemistry packages.

We made an open source community organization to host and maintain typst chemistry packages. Our goal is to improve interoperability between chemistry packages, so users can define molecules/elements once and use them everywhere. We are actively working on new features as a development team, so if anyone is interested, please come and join us! If you are thinking about a package or are a chemistry package maintainer please reach out. Also maybe it would be cool to have someone from the typst ...

[prime robin]

Would've been cool to have this as a team under the org, but it is what it is

[sullen pivot]

Correct me if I'm wrong, but it seems to mostly be a one person project?

[prime robin]

I saw like two contributors but that all I checked for

Or did you mean the community org?

[sullen pivot]

Bit strange to create a community before you even have a widely used package

[sullen pivot]

I didn't check all of them, but it seemed to be 99% the guy who posted the discussion thread

[prime robin]

🤷‍♂️

typst-community was created before any of us here even know about it

[prime robin]

yeah i saw that but this still splenters the community orgs