Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
On Fri, 2 Jul 2021, Jan U. Hasecke wrote: > > Dear Hans, > > thanks for the hint to the repo. I remember that it was mentiooned before. > > Am 02.07.21 um 10:42 schrieb Hans Hagen: > > official : https://bitbucket.org/phg/context-mirror/src/beta/ There is also github: https://github.com/contextgarden/context-mirror which simply mirrors the bitbucket repo. > Is there a how-to-bootstrap-from-repository? How can I get a running > context with the repo? These repos contain just the contents on texmf-context, but not the binaries (or sources of binaries). You need the binaries (and fonts!) to get a working installation. Aditya___ 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
Dear Hans, thanks for the hint to the repo. I remember that it was mentiooned before. Am 02.07.21 um 10:42 schrieb Hans Hagen: official : https://bitbucket.org/phg/context-mirror/src/beta/ Is there a how-to-bootstrap-from-repository? How can I get a running context with the repo? 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
On 7/2/2021 11:56 AM, Jan U. Hasecke wrote: Dear Hans, thanks for the hint to the repo. I remember that it was mentiooned before. Am 02.07.21 um 10:42 schrieb Hans Hagen: official : https://bitbucket.org/phg/context-mirror/src/beta/ Is there a how-to-bootstrap-from-repository? How can I get a running context with the repo? no, not yet ... we want to do it 'right' from the start - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
On 7/2/2021 9:38 AM, Jan U. Hasecke wrote: Am 02.07.21 um 01:07 schrieb Bruce Horrocks: 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. Thanks for this hint. This might solve one more problem. We would like to pin the installation to a version that is known too work. BTW: Are there plans to use a GitHub repository or an alternative to it? As that would ease pinning a bit. All uploads end up here too alsk kind of an archive: official: https://bitbucket.org/phg/context-mirror/src/beta/ experimental : https://github.com/mojca/context2 The official oen can be checked out, the experimental one is a playground because for quite a while Mojca and I have some ideas for a more extensive install on github which would then involve: -- core context code (with luametatex in source tree too: tex/texmf-context in the distribution -- the minimal set of resources: tex/texmf in the distribution -- binaries (which is the more complex part) -- modules: texmf/modules So, basically several repositories alongside (totaling to the amoutn we now have in the zips). We then have doif-it-yourself-zips, the garden installer, the lmtx self updater and install-from-github as alternatives. I have a sort of proof of concept for it. We looked into the binary bit and things have changed a bit over the years so maybe it's more doable now. One of the complications is always that it depends on helper programs: - zips are easy as all systems have it (ok, some linux distributions don't install unzip but one can easily add it) - the garden install needs a matching rsync (we need to ship on for windows and sometimes a mismatch will require an update on other platforms); it reminds me that we have to swap the cygwin bins by mingw bins; anyway. one problem is that organizations block the port - the lmtx installer needs a (luametatex) binary which is no big deal; it uses http and there might be organizations that demand https and ssl keeps evolving so in the long run it can fail to update older installations (it anyway means that we need to also ship e.g. curl or libcurl (the later works ok for us); no big deal but more work) - a github install demands that git is installed; that itself is a big piece of software (a small git binary for windows is already 200 MB due to all the dependencies while actually we only need a stupid fetch); the gh binary is still 25M but might be a solution, apart from the fact that we then expect users to have a recent bin ... will a 5 year old installation update?); of course users can also decide to completely do it themselves (check out etc) but for a local project-specific run one doesn't want all those gigs So, each approach has pros and cons, and we need to prevent lock into some specific technology. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl - ___ 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
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 wil
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
Am 02.07.21 um 01:07 schrieb Bruce Horrocks: 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. Thanks for this hint. This might solve one more problem. We would like to pin the installation to a version that is known too work. BTW: Are there plans to use a GitHub repository or an alternative to it? As that would ease pinning a bit. 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
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 ___ 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
Hi Taco, thanks for this hint. Am 01.07.21 um 08:44 schrieb Taco Hoekwater: I would put the whole context distribution in the git. That way, you can potentially hotfix something centrally. Would you put texmf-cache into .gitignore? Or is the cache portable to other machines? 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
> On 1 Jul 2021, at 13:31, Jan U. Hasecke wrote: > > Hi Taco, > > thanks for this hint. > > Am 01.07.21 um 08:44 schrieb Taco Hoekwater: >> I would put the whole context distribution in the git. That way, you can >> potentially hotfix something centrally. > > Would you put texmf-cache into .gitignore? probably, but it depends on how homogenous your setups are. In principle texmf-cache can be shared, but only if nobody has personal files. > > Or is the cache portable to other machines? > > 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 > ___ — Taco Hoekwater E: t...@bittext.nl genderfluid (all pronouns) ___ 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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
On Thu, 1 Jul 2021, Taco Hoekwater wrote: > 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. And that also makes sure that all your editors are using the same version of context. If everyone installs their own versions, debugging can be a pain. Aditya ___ 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 ___
[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 ___
Re: [NTG-context] Rolling out a pandoc-context publication workflow in an organization
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: t...@bittext.nl genderfluid (all pronouns) ___ 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 ___
