Introduce a proper package structure

[slarse]

A pre-requisite for a unified test suite (see #309) that can be run with CI is that the project is properly packaged, as modules will not be importable otherwise. This essentially requires three things:

1. A setup.py with the most rudimentary settings.
2. An __init__.py file in every directory housing Python modules.
3. Valid identifier names for all modules and directories.
   • I.e. no spaces!

We can keep the directory structure that is currently present, in which case each directory becomes it's own package (can still be managed by a single setup.py). We can also gather all top-level directories into a single top-level directory (called maybe algorithms), such that the whole project becomes a single package with multiple sub-packages.

To be clear, what we absolutely must have to run tests with CI is that all modules are importable from the root of the project.

Both are easy to implement. Any thoughts?

[slarse]

Going through the project, we've started finding a few troublesome import statements. For example, in data_structures/hashing/double_hash.py, there is a mix of explicit relative importing (i.e. prefixing an import with .) and absolute importing. The absolute importing is however relative to the data_structures/hashing directory, and as such won't work from the root of the whole project. Looks like this:

# explicit relative
from .hash_table import HashTable
# absolute, but semantically relative to the `data_structures/hashing` directory
from number_theory.prime_numbers import next_prime, check_prime

This apparently somewhat works in Python2 (if the cursor is in the data_structures/hashing directory), but it does not work at all in Python3. We will need to fix those those things in addition to the points listed in the initial issue.

@poyea We will go ahead with this refactor of the overall project, because it is absolutely necessary for us to be able to proceed with #309. Because of requirements from the university (we must measure code coverage), we've have little choice but to go with the single top-level package layout.

[cclauss]

Should this issue be closed given that pytest currently runs 373 tests on every pull request?

[slarse]

@cclauss I'm not invested in this so I don't mind if you close it. There's still a case to be made for properly packaging the project, because as it stands some directories are stand-alone packages while some are just directories. The problem with mixing and matching like that is that importing modules across different parts of the project becomes very difficult (sometimes impossible) to do consistently. For example, if something from the data_structures directory would like to use something from the hashes directory, it gets a bit complicated without proper packaging.

We found that running tests from a single test suite (i.e. not doctests spread all over the place) was impossible without packaging. With packaging, we could then example run essentially the same tests on all sorting algorithms that share similar characteristics (see this pr), making it very easy to test a new sorting algorithm. But there is of course added complexity to pay for that high level of code reuse.

Essentially, if you think the current setup works well enough for you then by all means, close this issue.

[github-actions]

Stale issue message