1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
---
date: 2023-08-29
title: "Releasing Raku modules with fez"
tags:
- Argo
- Raku
---
Last week I got a message on Matrix, asking me to update one of my
[Raku](https://raku.org/) modules,
[`Config::Parser::TOML`](https://git.tyil.nl/raku/config-parser-toml/). One of
the dependencies had been updated, and the old one is no longer available
through the module installer `zef`. Its not that big a change, and there are
tests available, so its a reasonably small fix on itself.
Recently I've set up [Argo Workflows](https://argoproj.github.io/workflows/) for
my CI/CD desires, and I found this a good and simple Raku project to try and
incorporate into a workflow. Since I had some additional quality checks ready to
use in my workflow, this has resulted in [REUSE](https://reuse.software/)
compliance for this Raku module, in addition to the regular `prove` tests
already available in the project. Additionally, the de facto default module
authoring tool `fez` also brings a few new checks that have been incorporated.
While all that is good, there were some annoyances I encountered while
configuring this. Notably, I've found `fez` to be a chore to work with when it
comes to non-interactive use. All CI/CD jobs run in their own Kubernetes pods,
and _should_ not require any interaction from myself during these runs. I am
writing this blog post mainly to write down the annoyances I encountered, hoping
that `fez` can be improved in the future.
Lets start with the first issue I encountered while setting up the workflow:
`zef install fez` fails by default. `zef` gives the advice to `--exclude` one of
the dependencies, and going by the issues reported on their Github repository,
this seems to be accepted workaround. However, I'd argue that this workaround
should not be needed to begin with. Especially seeing as `fez` works fine and I
have absolutely no clue what this `z` is or how I can supply it. Either drop
this dependency, or document its use and upstream so people can package it.
The second issue I encountered was with the `login` functionality of `fez`.
There seems to be no way to handle this non-interactively. The way around this
for me has become to use `expect` scripts, but this is obviously not very pretty
and will break whenever the interactive interface of `fez` changes. A good means
of non-interactive authentication would be great to have. I've considered to
just mount `fez`'s config/cache into the containers, but the documentation warns
that tokens aren't permanent to begin with.
Next up there's the actual `upload` command. I'm running it twice in my
workflow, once with `--dry-run` and once with `--force`. The first one is done
as a preliminary quality check to see if there's any obvious issues that ought
to be fixed beforehand. I noticed on a subsequent run (the one with `--force`)
that the _dry_ run isn't all that dry. It leaves an `sdist` directory, which in
turn will get included in the next step. There's a flag to create this `sdist`
directory, but no flag to do the inverse. My solution is to end this step with
`rm -fr -- sdist` to clean it up again.
And lastly, when all quality assurance checks have passed, the `fez upload
--force` command is ran on the working directory. I'd rather not force anything
here, but the alternative is that another interactive question pops up and the
job hangs forever. I don't know all the possible prompts `fez` can generate, and
for this one I didn't even bother to try and look that up. Rather than a
`--force` to practically say "yes" to everything, I'd prefer an option to say
"no" to everything, failing the pipeline immediately.
Another pet-peeve of mine is that `fez` seemingly doesn't use exit codes. No
matter what happens, even something quite important such as `login` with
incorrect credentials, it _always_ returns `0` as exit code. This should
obviously be fixed sooner rather than later, as it is quite simple and it is the
basis for _many_ systems to check the exit code to deduce something is wrong.
Uploads of module updates are currently working, which is good, but I feel like
a lot of workaround code I had to write should not be necessary. If `fez` can
fix these issues, it will be much more of a breeze to use, which in turn
hopefully encourages more automated testing and distributing of Raku modules.
This can be a great boon for the module ecosystem and overall community.
|
