Relationships

The pysal package would have each of the remaining packages as submodules.

Each of the remaining packages, other than pysal-core, would have pysal-core as a dependency via import.

This would facilitate different types of use cases for the library as well as the individual packages.

Use cases

All in one installation

pip install pysal

or

conda install pysal

Pick and choose

pip install pysal-points pysal-viz

or

conda install pysal-points pysal-viz

Package naming conventions

In some cases (i.e., pysal-points) the name has been extended to differentiate pysal from a general library name (points). This is because each of the repositories should be a package in its own right and thus installable via pip where an unambiguous name is required.

Standards for Top-Level PySAL repositories

To faciliate use of the top level projects within the PySAL meta-package, the former repositories may consider the following conventions.

Code layout

Testing conventions

PySAL has relied on nose for integration tests, so the directory structure given above would allow for integration testing under the new organization scheme.

Documentation

In contrast to the current approach where documentation is built across all the submodules to generate the PySAL documentation, this new model would have lighter weight documentation for the meta project that would simply link to the documentation of the individual modules. Maintainers would be reponsible for the documentation of each module.