Hi,

On 1 Jul 2021, at 08:02, Jan U. Hasecke wrote:

I come up with the idea of an "organizational context distribution" that has all requirements preinstalled. That could look like this:

I would put the whole context distribution in the git. That way, you can potentially hotfix something centrally. Best wishes, Taco — Taco Hoekwater E: taco@bittext.nl genderfluid (all pronouns)

On 1 Jul 2021, at 07:02, Jan U. Hasecke wrote:

If we use the current lmtx distribution, all editors would have to install ConTeXt with the install.sh script on their private computers, then we would either call a post installation script to clone the repositories in texmf-project or to clone them in another folder and set links to texmf-project. Linking seems better as I am not sure what "context generate" would do with the .git folder inside the repositories.

One option you might try, if your cooperative has a web-server available to editors, is to store your own ConTeXt repository. That way you can update the LMTX version when you are ready to. This works because "install.sh" can have a "--server" parameter supplied. By default it goes to lmtx.pragma-ade.com/install-lmtx but if you were to copy the install-lmtx directory and host the copy on your own server at the same path, then you could 'freeze' your LMTX version until you were ready to change. Since editors might run the install.sh themselves, you would probably want to tweak your local copy of install.sh to only install from your own server. When a new version of LMTX comes out, and when you have the time, you can install normally on a test machine and run whatever regression tests you want. Once happy you take a fresh copy of "https://lmtx.pragma-ade.com/install-lmtx/texmf-context.zip" onto your server and ask your editors to run install.sh at their own convenience. — Bruce Horrocks Hampshire, UK

Hi, in case you don't know it already, for your use-case you might also be interested in this workflow: https://oa-pub.hos.tuhh.de/de/ It's a publishing workflow for OA-Journals. IIUC, the interesting part (in this context here) is that they use Gitlab, author in markdown, and whenever you push a commit, Gitlab actions are used to produce the final output. I think they use Pandoc and LaTeX with Docker Images, but maybe it could be possible to set something similar up with ConTeXt... Denis

-----Ursprüngliche Nachricht----- Von: ntg-context Im Auftrag von Jan U. Hasecke Gesendet: Donnerstag, 1. Juli 2021 08:03 An: mailing list for ConTeXt users Betreff: [NTG-context] Rolling out a pandoc-context publication workflow in an organization

Dear all,

in the last weeks I asked more questions than I normally do. The reason is that my organization is discussing to roll out a markdown-pandoc-context publication workflow.

Some time ago we started to use context to produce flyers and some other documents. In fact I was the only one to use it. The results are so good that we discussed how to use it more often.

Currently we use LaTeX to produce our legal documents, terms of services etc. With ConTeXt we are able to meet our corporate design guidelines and to produce good looking and individually designed documents.

But our authors and editors were not willing to use ConTeXt directly so that we decided to look into Pandoc and use Markdown as authors input markup. Markdown is much better supported by text editors than ConTeXt.

The main problem for me is to come up with a good organization of the ConTeXt workflow so that it is easy usable and meets our requirements for quality management.

These are quite strict. We are a Debian based cooperative and the majority of our editors also use this distribution on their private computers. Some use a MacBook, only one uses of Windows.

For this reason we would like to stay with the Debian ConTeXt, which I never used as it is quite old. The same is true for Pandoc which made some improvements in the last years and also is very old in the current Debian distribution. As we did not decide this issue I can't say how much I have to refactor our styles to meet the older versions of ConTeXt.

Apart from this I have to organize our style files and ressources, anyway.

In another thread Hans said how to use these folders. Thanks a lot.

texmf-local : maybe configurations texmf-project : stuff you're working on (styles) texmf-fonts : fonts you downloaded or bought

All our styles and our shared image folder are versioned by git so I think that I either put links into texmf-project pointing to our style repository and to our image repository to have easy access to these ressources no matter how we call context or to put them into texmf-project directly. (We did not decide yet whether we call context from pandoc using a tmp directory for building or directly from our build script.

If we use the current lmtx distribution, all editors would have to install ConTeXt with the install.sh script on their private computers, then we would either call a post installation script to clone the repositories in texmf-project or to clone them in another folder and set links to texmf-project. Linking seems better as I am not sure what "context generate" would do with the .git folder inside the repositories.

All document projects are in their own repository. Currently we use a build script to call pandoc with an individual set of arguments including a custom context template which is stored in the document repository, also. Inside of this template we include all the environments we need for this particular document. We have a lot of small environments to reuse them in different document types.

This is our plan so far.

But to role out this successfully I would like to ease the way to a working pandoc-context installation for our editors. Do you have an idea how to do this?

I come up with the idea of an "organizational context distribution" that has all requirements preinstalled. That could look like this:

We have a repository:

hs.lmtx

which contains the install script and all our ressources (images and styles).

Our editors would clone the repository and just call the installation script to download the lmtx distribution. Afterwards they are ready to start as we would point to the right context executable in our build scripts.

Problem: What will happen if our editors do a git pull in hs.lmtx and a "context generate"? There are also concerns if something breaks after updating context with the install.sh. Is there a way to reset the installation to a given point release? How do you solve this in a production environment? On my private computer I sometimes install a new version of lmtx in a "staging" folder try it out and redo updating in my "production" folder.

I think I will try this out but I am happy if you have any comments on this.

TIA juh ________________________________________________________________ ___________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ________________________________________________________________ ___________________