Closed betatim closed 5 years ago
bump
+1
Could you do me a favour and review #2 before I merge it to master? I've submitted the underlying release to CTAN but it would be nice to give the structure of this repo a little extra thought. Maybe you prefer to have the .sty
and the example separated from the generator etc. :)
Hi Kevin,
If you want I can open a pull request and merge my current project which is actually based in your project.
Actually, I did a pure bash
generator so we could have the sty
build automatically with no external script dependencies. Also, I included the official font-mfizz repo as a submodule
so we can always build it whenever they release a new version
Check it out here https://github.com/codextremist/latex-fontmfizz.
Also I included a Dockerfile with the font-mfizz development environment, so we can generate our own SVG files and send PRs to them
Hi Felipe,
ah the beauty of FOSS 😃 If you're too lazy, someone else will do it, nice! Now I almost feel like I wasted the afternoon yesterday. 😄
Seems like I had the same idea with including their repo as a submodule. I agree that having Python and especially jinja2
as a (at this point even implicit) dependency is not ideal.
Now that the CTAN release is done anyway, maybe we can take a step back together and think about how to separate the concerns. As far as I see it there are two use cases:
My original idea was to have a repo that is a 1:1 reflection of what's available in CTAN. Now with the (two) generator(s), there are a bunch of possible ways:
.sty
from scratch. Ideally automated and/or without external dependencies. And ideally also with a quick way to generate a CTAN release.Let me know what you think. I'd be more than happy to ditch my Python-based solution if it means people will be able to generate the file with less hassle.
Cheers, Kevin
Hi Kevin,
I'm not familiar with CTAN, actually I have never worked with CTAN before. How they manage new releases and versions? Can we release the packages automatically or do we need to perform any manual steps?
One additional step to the ones you already added is asking the font-mfizz administrator to add a Github Webhook to us, so we know there is something new in their master branch. That would be the trigger for our build script to generate the sty
with new icons (and possibly push it automatically to CTAN)
AFAIK, CTAN is the central (La)TeX package repository. If I understand it correctly, it's where tlmgr
gets its packages from. So for example after fontmfizz was released on CTAN the first time around, a few days later by running sudo tlmgr update -all
you'd get it into your local TeX distribution.
Their release process is anything but automated. There's an online form that one needs to fill out and the uploaded zip will be manually processed by a human. (If we want to go crazy, it might be possible to send that form automatically but they might not allow cross-site requests to prevent spam…)
I like the idea of asking for a webhook on font-mfizz. Setting up Travis to automatically produce a release (at least as far as GitHub is concerned) should be easy. Uploading that manually to CTAN is not a lot of work :)
:+1: for travis to build things. Not sure about the submodule and the webhook. submodules seem to always cause pain (in the long run) and for the webhook I think if travis builds everything then all that is needed for a new version is that someone submits a PR updating the version number in the docs etc and then travis builds a new release. One thing to investigate is where could travis upload the files it creates? On CircleCI you can store build artefacts that are accessible after the build completes (-> download the zip, upload to CTAN), not sure what travis has.
The docker icon is missing. Could you point me to some instructions on how to add it? PR will follow.