Extraordinary agendum - Heiko

• Regarding subplot#20 (There’s no way to specify a scenario only needs to run conditionally)
• We referenced subplot#228 (Does not support labelling of scenarios)
• We also spoke about the USING syntax from Lars’s and Daniel’s conversations in 2017 (used to be at: https://blog.digital-scurf.org/posts/yarn-architecture/).

We discussed the fact that Heiko wishes to run tests which might cause the user problems if they run them in the wrong setup. Daniel suggested that there are a number of different ways we might look to meet Heiko’s goal which is to ensure that users do not accidentally run the ‘delete all my files’ scenario unless they really meant to.

One option which Daniel suggested was to create a separate template which generates a main() function rather than relying on the #[test] attribute. This would be the simplest piece to implement; but it would require that all the bindings were taught about this new template in order to make it work.

Another option Daniel suggested was to add some kind of configuration optionality to Subplot templates which would permit the templates to switch functionality on and off based on those configuration values. We’d probably want those to be specified up-front in the template.yaml but then perhaps we could envision something along the lines of subplot codegen -o examples/dangerous.rs -t rust -C mode=standalone dangerous.subplot or even allowing dangerous.subplot to specify configuration values in the impls block.

Lars then discussed a little about how unit/integraion/system tests relate to one another, and explained a little about how Subplot’s Rust scenarios might run in parallel whereas the Python runner executes serially always due to Python being unpleasant for us to implement parallelism here.

We then discussed environment management and situations in which it’s a good idea for subplot scenarios to manage resources (e.g. starting a server independently for each scenario) vs. having resources managed externally (e.g. starting a server before running cargo test and then tearing it down later).

We had a non-subplot chat about virtual cards and the pain they produce.

Outcome (ie. our work goals for now)

We believe that the alternative-output mode for templates is the most desirable approach. We’d want both standalone vs. libtest and parallel vs. serialised.

Lars asked if we could temporarily solve Heiko’s problem with Python, but Heiko wisely decided that adding Python to his codebase would make everyone sad.

Actions are documented at the end of this post.

Actions from last time

• DONE: Lars to add to decisions document to lower threshold for making refactoring to improve code quality
• PARTIALLY DONE: Lars to look at what it would take to use the pulldown_cmark parser for Markdown, instead of Pandoc, and make a concrete proposal of how to approach that.
  • proposal is not written down, but in summary: we’ll use the Markdown parsing from Lars’s ikiwiki clone, which gives us an AST modeled after HTML, and this will let us not use Pandoc for parsing at all
  • later on, we may choose to generate HTML ourselves, and drop direct support for generating PDF, and thus be able to drop the need for Pandoc at all; however, this is speculative
• STILL NOT DONE: Daniel to open an issue with Cargo to discuss binary-only dependencies.

Assessment of the iteration that has ended

We had chosen the following issues for this iteration:

• DONE: container#4 – Container is based on debian:buster - use bullseye instead?
• DONE: container#5 – Dockerfile could maybe be simplified
• NOT DONE: web#4 – Review FAQ
• DONE: subplot#239 – In metadata, author is a single string
• DONE: (double-checked done) subplot#281 – Parsing markdown with Pandoc doesn’t handle basedir

Discussion

The gitlab.com hosting situation

We reviewed the billing page for Subplot on gitlab.com. It all looks OK. We’re over the limit on seats, but it seems we can increase the seats for free.

We will review the billing page every iteration or two.

Repository review

We reviewed issues updated since the previous meeting, merge requests, and CI pipelines for all the projects in the Subplot group on gitlab.com.

Subplot Container Images

• Open issues: 1
• Merge requests: 0
• Additional branches: 0
• CI: OK, ran Saturday morning

subplot-web

• Open issues: 1
• Merge requests: 0
• Additional branches: 0
• CI: Ick, OK.

subplot

• Open issues: 46
• Merge requests: 0
• Additional branches:
  • docgen-cmark, Lars is keeping this around for reference for future changes
• CI: OK

Recurring items issues

There are some issues tagged recurring-agenda-item in the issue tracker, which we discuss in every iteration meeting.

• subplot#119 – Subplot is in not in Debian unstable
  • we will work on reducing Subplot dependencies that aren’t already in Debian
  • need the dependency list; we are not targeting bookworm

Goals

Goal 3: Current goal

Subplot is altered to treat a YAML document as the root of any subplot document, permitting multiple markdown files to be joined into a single scenario set or output document. We remove our dependency on Pandoc’s AST for internal document representation, and support a better range of document metadata as a result. We will use marked data types where possible to permit better provenance information in error and warning messages; and we will strive to reenable the reference tests such that we can make a statement to the effect that post goal 3, we do not intend to make further breaking changes to the input formats or primary behaviours of Subplot.

(Related issues on gitlab)

Goal 4: Planned

This goal is very likely to change. This is merely an initial sketch.

We’ll improve documentation and generally aim at making Subplot more plausibly usable by people outside of the Subplot project.

(Related issues on gitlab)

Plan for new iteration

Issues

We spoke about:

• subplot#291 (Could do with a user guide or Subplot book) Daniel pointed out that we need to start having somewhere to put some content into place. We agreed that the primary rendering should be HTML. We chose to use subplot docgen as the initial rendering engine. We chose for Ick to render things into doc.subplot.tech for now. Lars will set up build etc. for this
• subplot#305 (Maybe create binary releases?) Lars is going to have a go at doing this.
• subplot#308 (Allow continuing commands across linebreaks) We labelled this goal 3, active-discussion, and added some notes around choosing mail-style for now.
• subplot#309 (Lars needs a Subplot release) We agreed to do a release, Daniel will set it up. This will be 0.6.0

We intend to work on the following issues (Subplot milestone 7):

• web#4 – Review FAQ
• subplot#309 – Lars needs a Subplot release
• subplot#291 – User guide/book
• subplot#305 – Maybe create binary releases?

Actions

These are in addition to work on issues chosen for this iteration.

• Daniel to write up an issue describing configurable templates, how they would look from the user perspective, and from an implementation perspective. Then to request feedback from Heiko.
• Once that’s done, Daniel or Lars to write standalone mode for Rust template.

Meeting participants

• Daniel Silverstone
• Lars Wirzenius
• Heiko