Same for mtiLib later on
Moving forward, I think this pattern of making modules executable instead of adding new pyft* tools is the way to go. pyftmerge and pyftinspect can even be removed as they are not widely used.
Do you mean the "Tools" folder? Yes, that can be removed.
But I think the setup.py should still create executable console scrips using setuptools entry_points.
The Tools folder is mostly irrelevant. I meant:
python -m fontTools.XXX is the way to invoke them. Or we can install a catch-up command, pyft, or fonttools, that does that. So you'd say fonttools feaLib ...All I mean is that we don't want a growing list of pyft*** commands to pollute $bindir
+1 for fonttools [tt|fea|mti|…]
following up on f5bf9b04de26cf5f439c743df47c89e53457b031, I'm not 100% convinced about coupling any fontTools.* sub-module (e.g. ttx, subset, varLib etc.) with a corresponding fonttools {sub-module} sub-command on the command line.
If the aim is simply to avoid typing python -m fontTools..., one could just define a function in .bashrc like:
fonttools () {
python -m fontTools.$1
}
But I don't think that all fonttools' submodules are meant to be runnable as scripts. Nor we need to limit ourself to a single main() entry point per module, as we may wish to have multiple sub-commands per module.
Besides, the names of the modules ending in *Lib don't work well as sub-commands names; verbs or actions like "dump", "compile", etc. could be better, I think.
Perhaps, we should think about re-designing our command-line interface more explicitly.
And maybe also replace the deprecated getopt in ttx, or the custom argument parser in subset, with argparse, which supports specifying sub-commands.
And finally, I'm not a fan of that fonttools executable in the root of the repository meant to run fonttools without installing it. That reminds me of the Tools subfolder, which we got rid of because there are better ways to make platform-independent console scripts.
If one wishes to run fonttools without installing it in the system or user site-packages, one can install it in a virtual environment, with --editable if one also wants to modify the code in place.
And finally, I'm not a fan of that fonttools executable in the root of the repository meant to run fonttools without installing it. That reminds me of the Tools subfolder, which we got rid of because there are better ways to make platform-independent console scripts.
If one wishes to run fonttools without installing it in the system or user site-packages, one can install it in a virtual environment, with --editable if one also wants to modify the code in place.
Believe me, none of what you have suggested have worked realiably and efficiently for me so far.
Sorry to hear that.. ¯_(ツ)_/¯