MAINT: qiime2/q2cli -> rachis/rachis-cli name change

[lizgehret]

Description

This updates all references of qiime/qiime2/q2cli to rachis/rachis-cli in the following locations:

• doc/readme/help text references
• base command call (i.e. qiime etc etc -> rachis etc etc)
• cache temp dir default name
• script names & internal variable names (where applicable)

Still in progress for this PR (to-do's for myself):

• update ${usr_cmd} to accommodate qiime, mosh & rachis
• add a unit test to assert identical behavior when using qiime & rachis
• update qiime info unit test to include assertions about Parsl (separate PR) and rachis-cli (from q2cli)

BLOCKERS/EXTERNAL TO-DO's:

• q2cli -> rachis_cli in all relevant plugin recipes & environment files. this is required for distro rebuilds to now pull in the new/renamed cli and will need to happen before tests will pass in SKIP: paired PR for q2cli -> rachis-cli migration bokulich-lab/MOSHPIT#8 (I realized this after opening up new PRs, sorry for duplicating work @ebolyen)
  • plugins who pin/depend on q2cli:
    • MOSHPIT proxy (as expected)
    • q2-amrfinderplus
    • q2-fungal-traits
• update developer docs to reflect name change (I know this is already in progress bc this is what prompted the change in the first place but just putting here as a reference cc @gregcaporaso)

OPEN QUESTIONS:

• should we rename --qiime-type to --rachis-type? i'm currently thinking through this and ideally would like for --qiime-type to be transformed to --rachis-type (so that either can be used analogously). maybe exactly one of either should be required and will serve the same purpose. otherwise this would be a breaking change (so couldn't happen this cycle).
• should we rename our internal env vars? This would primarily be for future us/others' clarity to reduce confusion of multiple names floating around (i.e. QIIMETEST -> RACHISTEST, Q2CLIDEV -> RACHISCLIDEV)
• i think it's actually a breaking change that we've renamed q2cli to rachis-cli... something i just thought of.

AI Disclosure

• NO AI USED.
• AI USED.

AI Usage Details

Claude Opus 5 was used to assist with refactoring the tab completion script, and for doing a secondary repo-wide sweep to catch any name changes I missed.

[gregcaporaso]

I'm on it on the dev docs.

should we rename --qiime-type to --rachis-type? i'm currently thinking through this and ideally would like for --qiime-type to be transformed to --rachis-type (so that either can be used analogously). maybe exactly one of either should be required and will serve the same purpose. otherwise this would be a breaking change (so couldn't happen this cycle).

Can these be aliases, and we just show --rachis-type in the help text but either would work?

should we rename our internal env vars? This would primarily be for future us/others' clarity to reduce confusion of multiple names floating around (i.e. QIIMETEST -> RACHISTEST, Q2CLIDEV -> RACHISCLIDEV)

Can these be aliases, such that the new names take precedence over the old but either would work?

i think it's actually a breaking change that we've renamed q2cli to rachis-cli... something i just thought of.

In a user-facing way?

[ebolyen]

Can these be aliases, and we just show --rachis-type in the help text but either would work?

Since this is actually only used in the usage examples when assertions are enabled, I think it only impacts q2cli's tests of mystery-stew, so we might be able to get away with --type, since it's under the rachis dev assert-result-type which I doubt most are aware exists. We can still alias also.

Can these be aliases, such that the new names take precedence over the old but either would work?

No strong opinion from me, I think the choice should be related to our ambition to update our internal CI. Supporting both or even only the old form seems fine to me for now.

In a user-facing way?

I don't think this will actually end up being a problem. The interfaces will look the same qiime/rachis/mosh, and plugins should not be using q2cli directly (any that do are broken by definition in my view). There is a chance someone has implemented an interface that uses q2cli directly. I think this is ill-advised, but not as bad, so they can update their root import and everything else is pretty much the same. I don't think we need to or should support the internal package API of q2cli in any way. The stable API is the produced CLI.

[gregcaporaso]

I think the choice should be related to our ambition to update our internal CI. Supporting both or even only the old form seems fine to me for now.

That seems fine to me too.

plugins should not be using q2cli directly (any that do are broken by definition in my view)

definitely.

The stable API is the produced CLI.

Agreed.

And just FYI, I got a glossary entry in place for rachis-cli:

[ebolyen]

Some thoughts based on q2doc and our help text. I think we need to support dynamic names in the usage driver here.

This should probably look like an argument that can be given to the constructor such something like prog_name='mosh' (I don't love that param name, but whatever click calls it is probably fine), and we should also identify what our root name is when not initialized in that way mosh plugin action --help should write out examples with mosh as the root command.

The real issue we're going to run into for the latter case is the help-text cache which pre-renders the usage examples, but maybe we can somehow quickly template our way out of it? I am uncertain if that's workable or not.

[ebolyen]

Reminder to myself to update this in q2doc (and I think q2galaxy may care).

[gregcaporaso]

This should probably look like an argument that can be given to the constructor such something like
prog_name='mosh' (I don't love that param name

Maybe base_command? That's what I came up with when writing the glossary entry (but happy to edit that if we come up with something better).

but whatever click calls it is probably fine),

Agreed.