InvalidInput error when building with Fontship, missing rules?

[astianthus]

Trying to build the fonts with Fontship according to the instructions results in an error and no output files, for me. I am running Ubuntu 18.04 and I have cloned the repository as of the latest commit without making any changes. Output from fontship:

libertinus$ alias fontship='sudo docker run -it --volume "$(pwd):/data" --user "$(id -u):$(id -g)" theleagueof/fontship:latest'
libertinus$ fontship make
┏━ Welcome to Fontship ⁨v0.7.1⁩
┠─ Everything seems to be ship shape, anchors up!
┣━ Building target(s) using ‘make’
┖┄ Dumping captured output of ‘make’
make: *** No rule to make target '.fontship/LibertinusGitSerif-Regular-subr.otf', needed by 'LibertinusGitSerif-Regular.otf'.  Stop.
┎┄ End dump
┗━ Fontship run complete
Error: Custom { kind: InvalidInput, error: "Make failed to parse or execute a build plan." }

I have not managed to build the project in any other way and I am not familiar with Fontship, so I have no more specific idea of what could be causing this.

[ivo-s]

I have recently struggled with Fontship as well, but I have not encountered this. I used the approach in System Setup, that is making and installing it. Here the script will keep alerting you to any Python packages you're missing until the build succeeds. Some packages, like sfdnormalize, are not not in a standard pip repository and you'll have to pull them from Github. Eventually, everything worked out.

[alerque]

I don't know what happened over on Docker Hub, but 0.7.1 should not the "latest" release. The latest release of Fontship is 0.7.2 and fixes this issue. But was able to duplicate this on 0.7.1 and see that for some reason the "latest" tag on Docker Hub did not get updated properly. I'll look into that. In the mean time this should work if you use v0.7.2 instead of latest in your alias.

[astianthus]

Thanks, using 0.7.2 fixed this for me.

[alerque]

I've poked Docker Hub in the eye with a sharp stick and made it refresh it's latest tag to point to the same source commit as v0.7.2. This should have happened at release time and the glitch leaves us in a slightly awkward position where the two builds will not be the same. The Fontship source itself will be identical, but all the dependencies (things like fontmake, Python libraries, etc) will be whatever was current at the time of build, making latest with slightly newer tooling than was in the v.0.7.2 Docker build. I don't think it will matter in this case, but if something does go wrong that's likely why.

I just tested with v0.7.2 and latest and the master branch of this project builds fine with both.

$ docker pull theleagueof/fontship:latest

---

@ivo-s When installing Python dependencies manually you should be able to use the requirements.txt file to tell pip where to download those from. Does that not work for you?

Do let me know if you guys have any other troubles installing Fontship or getting this (or other) projects to build with it. I'm happy to work out the kinks.

[ivo-s]

Strange thing, I was looking for the requirements.txt and could not find it. Now I checked again and it is there, in plain sight. I don't have an explanation :D Anyway, the most problematic for me was sorting out how to do it with Anaconda. Some system packages provided libraries that were "overshadowed" by Anaconda and the versions were different...but that's just me and my Python illiteracy :-) Eventually I think I made it work with Anaconda's pip. For FontForge, I had to turn off Anaconda entirely :-) But once I had everything in order, it compiled nicely and works fine.

[alerque]

Sorry for the late catch of something else you should be aware of @astianthus, but I just noticed that your alias for running the Fontship Docker container includes sudo docker. This means you are running the container as root, something your really should not be doing. I don't think anything in Fontship is going to infiltrate your system, but just as a general practice that is a big no-no. Also it's likely to create all sorts of side effects such as the temporary build directories and resulting files being owned by root instead of your user. Nothing about the Fontship Docker build requires elevated system privileges to run, it should be run just as your regular user.

[astianthus]

Thanks for the heads up @alerque! When I try building as non-root I get the error docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/create: dial unix /var/run/docker.sock: connect: permission denied. See 'docker run --help'.. After looking at https://stackoverflow.com/questions/48957195/how-to-fix-docker-got-permission-denied-issue I found that running docker as root fixed the issue but I didn't realize it could be a security risk (as you can probably tell, I need to get better at this). That page also suggests making a Unix group for running docker. I am not sure how that really works, but https://docs.docker.com/engine/install/linux-postinstall/ seems to suggest that that would have the same security problems as running docker as root. Do you know what could be going wrong when I'm trying to run docker and if there is another solution to that?

[alerque]

@ivo-s It appears Fonship's repository has requirements.txt, but it wasn't distributed in the source tarballs you download of tagged releases. That will be fixed in the next release.

@astianthus I'm sorry I don't have that much experience with Docker on platforms that handle authentication differently than I personally have my systems setup. I know I run non-privileged containers, but also recall that was somewhat tricky to setup. You'll probably need to ask somewhere such as the Docker forums or StackOverflow for proper help with the actual Docker daemon config. Fontship just kind of presumes that part is working.