Skip to content

Planetary/PDS tools moving foward #45

@percurnicus

Description

@percurnicus

@spacerockjock

I'm about to get stared on a mer_spect equivalent (exportable ROIS, polygon ROIs, multiple ROIs, etc.) and everything is pointing to the fact that both pdsview and pdsspect (temporary name...have not thought about the name...) should depend on the very similar models and (also repeated use of the histogram tool). Essentially, pdsspect will be a more complicated tool than pdsview and will subclass and reuse a lot of pdsview's classes and tools. I could do this by making a new package for pdsspect and making pdsview a dependency, create pdsspect within pdsview, or start a new package that will house pdsview, pystamps, pdsspect, and any other future tools we create and deprecate pdsview and pystamps. My problem with the first option is it will become clearer as I make pdsspect how pdsview can be refactored even more to make it easier to reuse code. Then I will have simultaneous development on the two projects and that points me to option 2 or 3. My problem with option 2 is then pdsview is not clear on its purpose. The way it is setup/named right now is it is a one tool package and it won't be clear that there are other tools available. Which leads me to option 3 which I think is most preferable. It will be clear on it's purposes, allow for tools to reuse and sublcass each other much more easily, and make it far easier for the tools to interact/launch each other. The main concern is this will cause some reorganization on PlanetaryPy and we will have to take pdsview of of pip. I don't want to make any decisions about these tools moving forward alone and would love input on what people think is best moving forward.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions