Rename or unify binary names

[paravoid]

This is a big can of worms but necessary I think: a standard afdko build currently puts 29 binaries in /usr/bin. Many of them have really generic-sounding names (/usr/bin/spot?), and I've found at least one conflict with another tool already: /usr/bin/tx is also the filename of Transifex's client (a very popular translation tool) uses. One cannot install both that and afdko right now.

It'd be great if the binaries were named like afdko-$something, or hidden behind a main afdko binary or something like that to avoid this kind of issue.

Also see #211 which is sort of related.

[miguelsousa]

Renaming the tools is not an option.

[anthrotype]

A single afdko console entry point with sub-commands forwarding to each individual executable would indeed be nice to have. You could gradually deprecate the independent ones after a couple of releases or so.

[khaledhosny]

I’m pretty sure AFDKO’s tx is older than Transifex’s, they should be the ones asked to rename 😄

[paravoid]

Could you elaborate on why it is not an option? Thanks in advance for your time!

[miguelsousa]

These tools have been in use for decades. Many workflows depend on them. Changing their names is too disruptive, and your reasons are not strong enough.

[paravoid]

Right, I can see that. To explain a little bit my rationale: distributions have hard rules that disallow different packages from installing packages with the same filenames (Debian Policy 10.1 "Two different packages must not install programs with different functionality but with the same filenames"). So, this issue will block from afdko ever being included in Debian and probably other distributions.

The reason for that isn't crazy -- it's very rational for someone to expect that they can install afdko without also having to remove e.g. Transifex client from their system, which they may want for some other workflow of theirs.

afdko's 29 generically-named binaries have a high probablily for such conflicts. You could argue of course (as argued above) that you were there first but this isn't first-come-first-serve. Famously, both /usr/bin/node and /usr/bin/chromium belonged to other packages before Node.js and Chromium took those over as being more popular.

Finally, I also notice that 20 out of the 29 binaries are Python binaries, many of them separate entry points to the same broader module (e.g. proofpdf or otf2ttf), so it doesn't sound like it would even be that hard or crazy to unite into a few new executables (or just one). Not that this would solve /usr/bin/tx... but at least may help with future conflicts/expansions :)

How about this:

1. Decide whether everything should be fronted by an "afdko" executable, or a few multiple ones (e.g. "proofpdf");
2. Ship those new executable-with-subcommands immediately, while continuing to ship the old names for compatibility purposes;
3. Ship every piece of new functionality only under the new scheme;
4. Eventually, over time, make the old names an opt-in feature where users would have to explicitly ask for those old filenames. Could be even a separate pip package, afdko-compat or something like that.

[miguelsousa]

I appreciate your interest in the afdko. Feel free to fork it.

[paravoid]

I have no intentions to fork afdko (and I'm not sure why you're suggesting it). Just trying to make productive suggestions to help the project.