Unify param names

[DrLachie]

Deals with issue #73

I've changed psf_num_iter to decon_num_iter.
I've also left in the CLI_PARAM_MAP as it deals with things like roi_list going inside the crop parameter for example. Tested a bunch of permutations and seems to behave as expected.

[DrLachie]

Going to need to change the tests as the cli and decon tests will fail for the new parameter names

[multimeric]

Nice, this is much cleaner. I can see that you also actioned the change to Optional[Tuple] now that it has been fixed upstream.

Can you also pull from master to simplify the diff please.

[multimeric]

We will need to update the help here.

[pr4deepr]

Documentation should say the index of first and last slice slice, right?
@DrLachie

[DrLachie]

Yeah that's correct - I'll double check the help descriptions and update.

[DrLachie]

I've updated descriptions - I also added an extra logging line that includes the filename to be processed which is handy sometimes

[multimeric]

Looks good. Just noting that the field_from_model function I created copies the help from the Pydantic model if it exists. If the CLI usage and the Python usage are the same, I prefer to keep the description in one place. For example for devonvolution iterations:

napari_lattice/core/lls_core/models/deconvolution.py

Lines 25 to 28 in f57b489

	psf_num_iter: NonNegativeInt = Field(
	default=10,
	description="Number of iterations to perform in deconvolution"
	)

The description= argument is for the arguments that behave differently in the CLI, like physical_pixel_sizes, because it's helpful to explain to the user how to pass a tuple via the CLI. For the Python API this is self-evident.

[multimeric]

@DrLachie

[DrLachie]

Just so I'm clear, I remove the descirptions from the options in main and have it pull those from the models which is the preferable place for them?

I see some inputs have a help rather than descirption which doesn't behave the same way?

[multimeric]

Yes that's right. So the field_from_model tries to convert a Pydantic Field into a CLI Option.

• field_from_model(...) copies a model field and uses its description verbatim
• field_from_model(..., description=) lets you copy the field but change the description to make it CLI specific
• field_from_model(..., extra_description=) lets you append CLI-specific help in addition to the field's description
• Option(help=) doesn't copy from anywhere. The reason I used this in the past is because we had some CLI args like z_start that didn't correspond to a model field. I want to avoid doing this if possible, because it duplicates logic from the Pydantic model

[multimeric]

Closing as #82 has an updated version of this.