Closed nielsboecker closed 5 years ago
@boonwj Would appreciate your feedback on my ideas, and also if I forgot any key issues.
@UdomkarnBoonyaprasert you know this component best. Think about any potential issues this refactoring could create and how we could solve them, please.
Update: The foo_bar.type.py
naming scheme won't work because not valid python. Just leave out the postfix, through the directory / module name, it is obvious what kind of component it is.
Description
Our HoloPipelines code base has some major flaws, which already lead to architectural and maintanance-wise problems:
Suggested solution
Major refactoring! :rocket:
foo_bar.task.py
instead ofcompFooBar.py
tasks
instead of componentsservices
for more complex stuff, like format conversionwrappers
for external tools and existing solutionsclients
for communications like HTTPadapters
to abstract similar http calls, e.g. to the NiftyNet API we defined in the/models
directorypipelines
are made up entirely fromtasks
tasks
can usewrappers
for external services,services
for complex code,clients
if neededtasks
can implement some functionality directly inside them if appropriate, but it is preferred to extract as much as possible to other types of componentssnake_case
Suggested new structure
Files to delete
main.py
main.py
until now), uselung_and_airway_segmentation.wrapper.py
insteadbone_segmentation
Open questions
tasks
to have the same I/O? So can they implement exactly the same API, so that they can easily be shuffled around?Task
class, and have the other tasks be sub-classes of that?