Buildchain issue with ttfautohint

[bennetfabian]

Describe the bug In some cases the Makefile needs tweaks depending on the Python version.

When running the autohinting the Makefile assumes ttfautohint to be in $(PWD)/build/venv/lib/python/site-packages/ttfautohint. Depending on the Python setup it can also be $(PWD)/build/venv/lib/python3.9/site-packages/ttfautohint which would of course cause an error as the Makefile cannot find ttfautohint.

My suggestion:

1. Make python version a variable on top so it can easily be configured. OR
2. A command like pip show ttfautohint-py | sed -n -E -e 's/^Location: (.+)$/\1/p' (sorry if it's not a best practice command, I suck at sed) should be able to determine where packages in the virtual environment are installed. Appending /ttfautohint returns a safe to run path for ttfautohint.

Expected behavior Autohinting process should start.

Environment

• OS: macOS Monterey
• Python: 3.9.7 via pyenv

[rsms]

Hm. The env rule (which other targets depend on) should create a version-less symlink at build/venv/lib/python

Can you try the following:

cd your-inter-repo-checkout
rm -rf build/venv
make venv
ls -l build/venv/lib/python

Tell me if you get any errors and what the result of the last (ls) line is. For me, it's build/venv/lib/python -> python3.9

[bennetfabian]

Hm. The env rule (which other targets depend on) should create a version-less symlink at build/venv/lib/python

Can you try the following:

cd your-inter-repo-checkout
rm -rf build/venv
make venv
ls -l build/venv/lib/python

Tell me if you get any errors and what the result of the last (ls) line is. For me, it's build/venv/lib/python -> python3.9

Ahh, thats where we get different results. FYI: I made a brand new clone so the repo on my machine would be in the upstream state.

After rebuilding the Virtual Environment and running the ls, I get a different output: build/venv/lib/python -> python3

That's where the issue on the surface lies. The actual directory for the venv is python3.9 while the link leads to python3 (so the link leads to nothing). I will try to figure out if thats a pyenv issue by disabling pyenv and trying a Homebrew python version and then I will get back to you.

[bennetfabian]

Apparently pyenv does some weird things.

Take a look at what's inside the venv's bin folder

python -> python3
python3 -> /Users/bennetfabian/.pyenv/versions/3.9.7/Library/Frameworks/Python.framework/Versions/3.9/bin/python3
python3.9 -> python3

The symlink created in build/venv/lib seems to be based on the bin folder if I properly understood that command construction, right? Couldn't we possibly create the symlink based on the name of the Python directory that's actually in build/venv/lib? That would probably mean it would be less error-prone and vague.

Something like find build/venv/lib/ -type d -depth 1 | sed -E "s/build\/venv\/lib\/(.*)\//\1/g" (which is of course hacky and probably again not a best-practice) would return the same value as the $$(basename $$(readlink build/venv/bin/python)) does under Homebrew.

For comparison: echo $(basename $(readlink build/venv/bin/python)): python3.9 find build/venv/lib/ -type d -depth 1 | sed -E "s/build\/venv\/lib\/(.*)\//\1/g": python3.9

[Screwtapello]

If you're trying to run the Python command-line wrapper for the ttfautohint tool, you should just be able to run:

python -m ttfautohint

You shouldn't need to worry about the exact path inside the virtualenv; pip will put the package where python can find it, so let python do the search itself.

[bennetfabian]

If you're trying to run the Python command-line wrapper for the ttfautohint tool, you should just be able to run:

python -m ttfautohint

You shouldn't need to worry about the exact path inside the virtualenv; pip will put the package where python can find it, so let python do the search itself.

That worked! Would you consider integrating it into the Makefile replacing the current line 116? @rsms

That would make the build process more resilient to different build environments.

[rsms]

Thanks! Done.