I was thinking that it would not be a path but would be a colon separated list of CLI python code modules or functions. So for example set it to lsst.obs.base.cli (since we would have the code in the python path).

Then in butler command itself you do something like:

for module in os.environ["DAF_BUTLER_PLUGINS"].split(":"):

    blah = doImport(cls)

and maybe have the imported class import the subcommands to click somehow (I don't know what the equivalent of from x import * would be or how importing code registers with click.

Maybe it helps to be explicit and have the env var contain the actual command function (so lsst.obs.base.cli.register or somesuch).

Tim Jenness thanks for the clarification, I updated the description.

https://github.com/lsst/ci_hsc_gen3/pull/16

https://github.com/lsst/daf_butler/pull/258/

https://github.com/lsst/obs_base/pull/226

Tim, can you nominate anyone else you think should look at this?

Tim Jenness is this good for a CLO post related to these changes?

Topic: 

Butler and obs_base command line scripts have changed to a single command with subcommands

Tags:

hsc, butler, obspackages

Body:

The following butler scripts have been replaced with a top-level butler command, with git-style subcommands:

`dumpButlerConfig` is now `butler dump-config`
`makeButlerRepo` is now `butler create`
`validateButlerConfiguration` is now `butler validate-config`

Supported options have remained the same, but some of the names have changed with the intention of standardizing on common option names.

the ci_hsc_gen3 script `registrerInstruments` has been replaced with two commands for registering the instrument and writing the calibrations:
`butler register`
`butler write-curated-calibrations`

A list of all available `butler` subcommands is available by the standard `--help` option; `butler --help`.

The butler command is defined in `daf_butler`, but subcommand "plugins" are loaded dynamically so make sure you have `setup` the packages you intend to use before calling `butler --help` or attempting to use sub-commands.

Similarly, help for each of the subcommands is available by calling `butler <subcommand> --help`.

That looks okay. Not sure hsc is needed as a tag. Looking at it I do wonder if we want butler config-dump and butler config-validate as the subcommands so that they would be more directly config related and sort together in the help. Jim Bosch do you have an opinion on that?

we want butler config-dump and butler config-validate as the subcommands so that they would be more directly config related and sort together in the help

, and I think that's a pattern we'll want to use for other commands, too. On that note, I'd recommend butler register-instrument, as we'll also have (at least) butler register-skymap.

Looks good. Some minor comments on GitHub.