Currently, I'm not able to install FB inside a virtualenv. I'd like this so FB doesn't use my system wide dependencies. By using virtualenvs we can lock the dependencies in place for certain milestones.
The biggest problem is the headless FontForge.
I thought I'd bring this up because it is kind of linked to #1304
In the meantime you can do $ virtualenv --system-site-packages venv
then $ pip install -I -r requirements to reinstall all requirements, and thus make sure they are up to date. You'll still need a global fontforge.
I think it should be ready for you now, @m4rc1e , to install into a virtualenv based on the current code on the master branch.
If not, let me know what goes wrong.
@m4rc1e Please (re-)test this and reopen the issue if you still face problems with the current setup. Also consider whether your difficulties are the same as the ones @davelab6 describes on issue #1635 If so, then this should be kept close and the other issue tagged as a duplicate of this one.
This new has made my day. I'll give it a test today.
Alright, we're missing the googlefonts/tools dependency I think
â–’ [PSSSSEEEEEEEEFEEEEEEEEEEEEPEEEEESEEE.........................................................................................]
29%
Traceback (most recent call last):
File "/Users/marc/Documents/googlefonts/fontbakery/env2/bin/fontbakery-check-googlefonts.py", line 7, in <module>
main()
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/commands/check_spec.py", line 208, in main
distribute_generator(runner.run(), reporters)
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 679, in distribute_generator
for item in gen:
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 668, in run
for status, message in self._run_test(test, iterargs):
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 566, in _run_test
skipped, args = self._get_test_dependencies(test, iterargs)
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 537, in _get_test_dependencies
err, val = self._get_condition(name, iterargs)
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 400, in _get_condition
err, val = self._evaluate_condition(name, used_iterargs, path)
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 372, in _evaluate_condition
args = self._get_args(condition, iterargs, path)
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 515, in _get_args
args[name] = self._get(name, iterargs, path)
File "/Users/marc/Documents/googlefonts/fontbakery/env2/lib/python2.7/site-packages/fontbakery/testrunner.py", line 489, in _get
raise error
fontbakery.testrunner.FailedConditionError: The condtion <FontBakeryCondition:ttFont> had an error: ImportError: No module named fontTools.ttLib
`$ pip install git+https://github.com/googlefonts/tools' solved it. Please add googlefonts/tools as a dependency.
ImportError says fontTools
My bad.
$ pip install fonttools did the trick.
Btw, I installed this using PyPy using pip install fontbakery
You should use tox to automate running tests inside virtual envs. It will also help you catch packaging issues like these. And it will be useful when you get to adding python3 support.
https://pypi.python.org/pypi/fontbakery/0.3.2 does not list fontTools as a dependency.
but looks like Felipe already fixed that https://github.com/googlefonts/fontbakery/commit/1b71650c070b843b02271b29e3ce89b43cd0657e
he just needs to upload a new release
yep! I was expecting Marc to install from master by doing python setup.py install instead of isntalling from pypi (since the 0.3.3 release will only happen a bit later this week)
I strongly recommend that you always use pip to install, even from a local directory pip install . or pip install -e ..
The python setup.py install command will either use setuptools to install an .egg package (if setuptools is imported in the setup.py), and eggs have been superseded by the wheel package format. Or worse it will use distutils to copy the module to the site-packages, but then the user will not be able to uninstall it cleanly without messing manually with the python site-packages folders. From pip 10.0 (about to be released this or next month) it will no longer be possible to pip uninstall packages that were installed via distutils (i.e. python setup.py install on a setup.py that does not import setuptools).
When you pip install . on a folder that contains a setup.py file, pip injects setuptools before executing the setup.py script; behind the scenes pip will make a wheel and then unzip it to the site-packages; this also creates the .dist-info metadata folder that comes with wheels.
Finally, the python packaging authority (PyPA) are finalizing a PEP (python enhancement proposal) to allow specifying alternative build systems besides setuptools in pyproject.toml file, so that in the future one could use pip (or another similar installer) to build/install from source without a setup.py script.
So, in sum, please stop recommending python setup.py install.
Thanks a lot, Cosimo! This is very insightful.
if you're interested in the latest developments on packaging, you can subscribe to https://mail.python.org/mailman/listinfo/distutils-sig