Renaming of driver functions in a standardised way

[fclubb]

After discussion with @benbovy we think that it would be best to rename all driver functions and executables in a standardised way so that they can be installed and all linked together.

I suggest we go for every driver function being named lsdtt_whatever For example:

lsdtt_channel_extraction
lsdtt_chi_mapping
lsdtt_basic_metrics

[sgrieve]

My only objection to this naming scheme is that its a pain to find things on the command line. I would prefer:

channel_extraction_lsdtt
chi_mapping_lsdtt
basic_metrics_lsdtt

But that is just me being lazy 🤷‍♂️

[benbovy]

The advantage of using lsdtt as a prefix is that, if we have all the LSDTT programs installed somewhere in our PATH instead of a user folder (which I think would be nice), it would make them much more discoverable. Just type lsdtt<TAB> and see what is available.

[dvalters]

Would it be nicer to have lsdtt channel-extraction and then tab completion on the argument channel-extraction would still work

[dvalters]

then you could have stuff like:

lsdtt --help    # Lists an overview of all the analyses as well maybe...
lsdtt --version
lsdtt --other-stuff

etc

lsdtt channel-extraction --help     # Lists basic help for channel-extraction

[sgrieve]

Ah. Makes total sense. I was thinking purely about driver files as editable files, rather than binaries.

[benbovy]

Alsdtt main command and sub-commands would be great indeed!

How easy/hard would it be to implement this in C++? Right now, I'm rather thinking about a lightweight cmd-line wrapper (e.g., a Python script) that would simply call LSDTT executables.

[dvalters]

Yes I was thinking just a Python or Shell wrapper script called lsdtt. Python + argparse module would work well. It would parse all the arguments (e.g. channel-extraction [arg1][--options]) and then just pass them to the right C++ executables in a bin folder. As well as having some generic --help function 'cheatsheets' for running topotools.

[fclubb]

So in this case, the driver functions and executables should just be named like:

channel-extraction
chi-mapping
hillslope-metrics

etc.... Is that right @dvalters?

[benbovy]

I think that if there is a lsdtt wrapper script, then the names of the executables don't really matter. That said, it would still be better to choose consistent names and use a lsdtt_ prefix if those executables are also exposed to users.

[simon-m-mudd]

Agree: I think we have the executable called lsdtt_something and then a wrapper script. The wrapper script would be constructed on installation so that it always points to the correct executables directory no matter where the user has installed it.

[dvalters]

Yes - if it's a wrapper it will just search the bin directory for a matching executable of the same name (whatever that name is), and then pass the arguments to it. It needn't know anything about the internals of each executable, or even their names, as the most of the argument error checking is done in the C++ source code right now anyway.

It needn't even be constructed/built on installation but could just sit in the bin directory. (Then if you were working on a new analysis, you would only have to build your C++ executable for that analysis.).

The user's $PATH would just point to this bin dir making the wrapper script callable (and the other execs, if you wanted...)

[dvalters]

(I'm assuming there would not be an option to allow the user to install the bin dir in a 'random' location, separate from whatever the top-level lsdtopotools directory is called, neither an option to separate the lsdtt script from the folder (since it will be in the users $PATH), hence no need to 'build' this wrapper script on installation.)