Make repo package-able

[AdrianDAlessandro]

The repo structure is not currently consistent with the tooling used for building python packages. In particular, the data files are not in findable locations.

Ideally we should lift the severity of restrictions on dependencies for compatibility with other people's code.

Some requirements for this:

• Move run_app.py into the main module #72
• Might need to restructure the source code directory (src vs module name alone?)
• Consolidate the data/config files into the package and make poetry aware of them.
• Need to include data files with importlib (specifically in utils.py)
• Ease restrictions on dependency versions #71

[alexdewar]

I'm just looking at the last task ("Ease restrictions on dependency versions") and after a bit of reading I think we're probably fine to leave things more or less as they are. Apparently if you specify a dependency version as ^1.2.3, this is equivalent to >=1.2.3,<2.0.0 (see here). The poetry.lock file isn't used at all when you do pip install my_package -- it's just for developers. Given that this package is for a program not a library, I figure that's probably enough flexibility in dependency versions.

The only thing is that this version logic depends on packages using semver and in the case of the regex package, it's clearly versioned by date instead. So I suppose we might want to change that version to be regex = ">=2024.9.11" or something instead.

More info: https://python-poetry.org/docs/basic-usage/

[AdrianDAlessandro]

I'm just looking at the last task ("Ease restrictions on dependency versions") and after a bit of reading I think we're probably fine to leave things more or less as they are. Apparently if you specify a dependency version as ^1.2.3, this is equivalent to >=1.2.3,<2.0.0 (see here). The poetry.lock file isn't used at all when you do pip install my_package -- it's just for developers. Given that this package is for a program not a library, I figure that's probably enough flexibility in dependency versions.

The only thing is that this version logic depends on packages using semver and in the case of the regex package, it's clearly versioned by date instead. So I suppose we might want to change that version to be regex = ">=2024.9.11" or something instead.

More info: https://python-poetry.org/docs/basic-usage/

Sorry, I didn't see this comment before I made #71

This sounds good, and mostly in line with my expectations. The only thing is if we keep automatically updating the versions of these packages, won't we restrict compatibility with other packages that can only use older versions? I would've assumed we should set the versions to the oldest version that the package supports to make it it as compatible as possible.