Package Organization

Package Tree for wsatools

Organization guidelines

When choosing a module in this package for which to locate functions that are to be accessed by multiple curation tasks, follow these guidelines:

1. If the function can be grouped together with several other functions that work on similar data or towards a similar goal or purpose, then create a new module with a meaningful name: e.g. wsatools.SourceMerger was created to host all the functions that may be required to produce merged sources from detections in different passbands (or whatever).
2. For lone functions, look through the list of pre-existing modules and decide where it fits best. Mostly likely it belongs to one of these modules:
   • wsatools.DbConnect.CommonQueries - if its purpose is to retrieve or update data in the database.
   • wsatools.FitsUtils - for managing the WSA's collection of FITS files in any way.
   • wsatools.Utilities - if it performs generic manipulations on Python objects or for managing the WSA file system. No database connections should be made from here.
3. Finally, for lone functions that do not fit into any of the pre-existing modules then it should probably be left in the script where it was initially required (with a view of creating a new module for it if and when more functions are created that work towards a similar goal). Other curation tasks that require use of this function should then import this script to access this function. This is possible as our coding standards require all scripts to be "importable" (for epydoc's sake). Do NOT duplicate the function.