search

BICCN / cell-locator

manually align specimens to annotated 3D spaces
https://cell-locator.readthedocs.io
Other
19 stars 7 forks source link

change hard-coded kind parameter to default that can be overriden by a command line argument #213

Closed roby1kenobi closed 2 years ago

roby1kenobi commented 2 years ago

What's the problem this feature will solve? The AIBS Annotation Team would like to distinguish its pinnings from those of the Ephys rig operators. Adding a new kind of SpecimenMetadata (e.g. IVSCC tissue review) would enable them to do so.

Describe the solution you'd like

  1. Add support for an optional kind command line argument.

  2. Change hard-coded value for the kind value on line 804 of https://github.com/BICCN/cell-locator/blob/master/Modules/Scripted/Home/Home.py to a default value that can be overridden if the kind command line argument is specified.

https://github.com/BICCN/cell-locator/blob/26b770a06bd3c85c1c714cd9521548bc3970ca5f/Modules/Scripted/Home/Home.py#L801-L806

IVSCC MET project is trying to identify the pinnings of Ephys rig operators that require review. The Annotation Team is currently uploading new version of the IVSCC cell locations SpecimenMetadata. It is not obvious in the LIMS if a new version was saved by the rig operator or the tissue reviewer.

Alternative Solutions We could also work with an optional command line argument for state that could be used to indicate that there is a difference between cell location JSON documents for a Specimen.

Another option that would provide additional future-proofing: add an optional parameter that accepts key+value pairs so that additional parameters can be specified as a Dictionary and then just iterate through and append them to the end of the GET

Additional context Thank you for considering the request!

allemangD commented 2 years ago

Add support for an optional kind command line argument.

As --kind is fairly vague, I'm adding the optional parameter --lims-specimen-kind with default value IVSCC cell locations. If the parameter must be called kind instead, let me know.

Another option that would provide additional future-proofing: add an optional parameter that accepts key+value pairs so that additional parameters can be specified as a Dictionary and then just iterate through and append them to the end of the GET

Since the difficulty of adding parameters like --lims-specimen-kind is so low, I'm inclined to prefer that more explicit approach rather than more implicit key-value pairs. Do you anticipate values like this will be added often?