Project & packaging house-keeping
exhuma opened this issue · comments
NOTE: If there is interest, I can take care of the points noted below via a PR:
The project currently contains a setup.py
, a pyproject.toml
and a Pipfile
. To some degree, the docker-compose.yaml
and Dockerfile
could also be included in the "packaging" topic.
If there is an interest, I could look into consolidation of all those files. For example, with PEP-517, we could put everything into pyproject.toml
. Currently the project uses both setuptools
and pipenv
for dependency management. As setuptools
can do most, it might be beneficial to remove both setup.py
and Pipfile
in favor of pyproject.toml
.
pipenv
does offer a few convenient commands though and might still remain useful. An alternative (for locking) could be pip-compile
(from pip-tools
). pip-tools would be a tad more lightweight. But as it does not offer any real added value I don't mind sticking with pipenv.
The docker-compose file is not referenced anywhere in the project so it might just be a leftover from an older revision. I don't see any practical use of it at this moment and it could be removed for cleanup.
I would be happy to review and merge a PR that cleans up the packaging situation here. Most of my python packaging knowledge dates from the setuptools
era :)
This project is used both as a library for testing locally, as well as an application that runs on the web. It seems that you might need some dependencies for the web (eg sentry or gunicorn??) that you don't need for the library. Not sure what the best way is to separate these, or perhaps that's not even necessary.
I will look into that that (in fact, I'm already knee-deep in 😉)
I will add as much details as possible in the PR notes to explain my thoughts behind the changes. Considering that packaging is pretty diverse nowadays and subject to personal preference.
If anything is left unclear, feel free to ask or prod me as needed.
Thanks@ Resolved by #17