Thank you for the explanation @avalentino, and for the maintenance.

Could you please also update the installation with the apt install on the repo of pyaps and pysolid?

I agree that changing in mintpy setup.py is the way to go. Since this change will affect all the current users with existing installation methods, I prefer to wait for a future time to do this, when we have more compact script names and numbers.

OK, I will update the script prefixes in the debian package ASAP.

Regarding possible future evolutions of the entry points for mintpy, an option could be to provide a single entry point (mintpy) with multiple sub-commands. This one could live side by side with the current entry point for a TBD transition period.
If you think the the approach makes sense I could work to a PR in that direction.

Could you please also update the installation with the apt install on the repo of pyaps and pysolid?

sure, I will do it ASAP.

Could you explain a little bit more about the single entry point approach? Is that what gmt is using? And in that case, what people should do if they want to run non-mintpy commands?

I don't know well gmt but yes, the approach seems similar.
The single entry point (the mintpy script) will provide access to all functions currently provided bu the set of entry point currently provided via sub-commands:

$ mintpy -h

USAGE: mintpy [-h][options]

Long desctiption

Subcommands:
  ...
  pre_snap:          description
  smallbaselineApp:  description
  save_qgis:         description
  view:              description

To access the specific function:

$ mintpy smallbaselineApp [-h][options] <arguments>

Not sure about what you mean by "non-mintpy commands".
The idea is that, in principle, any function available in the mintpy python package can be (eventually wrapped and) exposed as a sub-command.

Thank you for the explanation @avalentino. Yes, this single entry point sounds great to me! A PR is more than welcome.

Very cool! Thanks!