googlefonts
Refactor packager
This is quite a major change which splits the packager up into multiple modules, tidies up the handling of upstream.yml files by making that into a class, removes the "interactive mode", and also rationalizes the CLI interface.
Instead of:
$ gftools packager "Family Serif" path/to/google/fonts/clone -p
$ gftools packager "Family Serif" some/directory
$ gftools packager "Family Sans" familysans.upstream.yaml -u
We now have:
$ gftools packager package-git --googlefonts-clone path/to/google/fonts/clone "Family Serif" --pr
$ gftools packager package-locally --directory some/directory "Family Serif"
$ gftools packager generate-stream --file familysans.upstream.yaml "Family Sans"
which is a bit wordier, but more self-explanatory and less magical.
Did you have a particular reason to remove the "interactive mode"? I use it all the time, find it really useful
At the moment I'm just trying to make things simpler. If it's very useful, I can certainly add it back again. But I think I would like to understand how you are using it. For example, when you generate the upstream.yaml and are then prompted to edit it, that is something that doesn't need to be in the packager itself; you could just have a command-line script which runs the packager and then opens upstream.yaml in an editor. But the part which tries to parse the YAML file and opens an editor if there are errors, I can see that being more useful.
For example, when you generate the upstream.yaml and are then prompted to edit it, that is something that doesn't need to be in the packager itself
Yeah, but the tool's goal continues to be to assist anyone who might use it to create a PR to GF, not only onboraders. If the option already exists, it doesn't hurt to leave it available even if it's not commonly used (like many flags for fontmake), I think.
But the part which tries to parse the YAML file and opens an editor if there are errors, I can see that being more useful.
This is the most useful part indeed, to find typos, missing info etc.
Also, when creating multiple PRs for different projects, it's really easy to make small human error. There the interactive mode has been truly helpful to alert you are making a PR from a different repository (e.g a fork instead of upstream when updating a PR). The intermediate step about forcing to override the upstream yml, has helped to prevent push to a wrong repo for related fonts of a big project. Eg. when doing ProjectA-Tamil-font after a ProjectA-Telugu-font. I don't have a full list of cases now, but there have been some others.
I added back in support for editing the YML file if the --interactive flag was set. The --force behaviour has not changed: if you are doing something destructive without the --force flag, it will fail.
I've been testing this pr out. Overall, I like the direction of having 3 seperate subcommands. However, I feel we can simplify further.
Personally, I'd go for just 2 sub commands:
# create an upstream yaml file.
gftools packager new google/fonts/fontfamily/upstream.yaml
I don't think we should offer multiple ways to build these upstream files. Also, they all seem to live in respective fontfamily dirs.
# pull in upstream files. -p makes pull request (could have a seperate push command like git but hey)
gftools packager pull google/fonts/fontfamily/upstream.yaml
I'll keep updating this with my thoughts as I play more.
I'm a bit confused by this - the three separate subcommands are:
- Write out an upstream.yaml
- Package a font into a local directory
- Package a font into a git repository
The last two are definitely different, and although we could consolidate them into one by testing for the existence of a .git directory, I'm trying to get away from that sort of magic.