Individual functions, entire modules or both? #3
Replies: 3 comments 1 reply
-
In general, yes, we can provide multiple levels of things, but I guess I'm not sure on how the specifics would work here - could you give some examples, ie maybe what you envision from one module that does many things (like ExpandOrShrink), and what you would envision from one module that does only one KIND of thing but with many options and therefore sub-sections of code (like IDPrimary or IDSecondary)? In my initial conception, the latter would only have one function, ie |
Beta Was this translation helpful? Give feedback.
-
Below is a simplified view of how I would like the interaction with cellprofiler_library to work. Ideally, I would like it to be as simple as intuitive as possible to convert a pipeline in the GUI to a script. For running IDprimary you can enter your desires for particular variables but for those you do not select leads to the typical CP default being selected (eg. 1.3488 smoothing scale in IDprimary). For a module like ExpandOrShrink with lots of varied options, I think the process should remain the same when calling the .run() method for ExpandOrShrink. Here, the user can select which operation and then add additional information for variables specific to each operation. If a variable is not provided, default and report back to the user that a default is being used as code executes. If an input variable is provided that isn't used for a particular operation, ignore and alert the user as code executes
While it doesn't make sense to have a .run() method for ExpandOrShrink since it's in essence a few distinct functions, I think having a .run() method for all modules makes sense from a consistency standpoint when writing a script for a pipeline. Though I do think that there should still be an option to pull out a particular function with something line |
Beta Was this translation helpful? Give feedback.
-
I can definitely see the utility of the structure you're describing; I think the major thing I'm not sure about is whether we expect our typical user to be someone who already is familiar with CellProfiler or not. I would hope it wouldn't be a REQUIREMENT to be familiar, in any case. Perhaps one way we could think about structuring this to please BOTH camps would be to have essentially both; a
and
|
Beta Was this translation helpful? Give feedback.
-
Should the interaction with CellProfiler library be calling single functions, or being able to call entire modules with input variables that represent all of the inputs a particular module may have. Is it possible to provide both?
For example, if a single function from a module is desired, it can be accessed with
module_name.function()
. However, for more complex modules with logic, perhapsmodule_name.run()
can be selected. In this latter case, I think it would be easier to translate a pipeline from the CellProfiler GUI into script form and then string it together with various visualisations etc, which would be great for repetitive workflowsBeta Was this translation helpful? Give feedback.
All reactions