EarthCubeGeochron/Sparrow

Python codebase reorganization

Opened this issue · 0 comments

The organization of our codebase is getting creaky and out of date. It would be worth a refactor to enable several priorities:

  • Better sharing of code between parts of the project (e.g., CLI, server, and importers)
  • Better delineation of plugins vs. core Sparrow code
  • Moving some functionality into libraries that can be shared with external projects

Broadly this reorganization will be important for Macrostrat and other efforts, as many of our code components developed in Sparrow are broadly applicable to other services.

The same reorganization needs to happen on the frontend and the backend, but it's a little more further along on the frontend already. I propose a monorepo structure for dependencies such as that outlined in this blog post. This issue in Poetry is also potentially useful.