Move away from poetry?

[Jacob-Stevens-Haas]

Hey @andgoldschmidt , what are your thoughts about moving away from poetry? At the very least, .gitignoring poetry.lock would prevent all the dependabot PRs that deal with dependencies of dependencies. Thanks to #14, I only use poetry as a backend on this project (and pip, venv for the rest). There are two (related) suggestions in line with removing the poetry backend. (a) changing pyproject.toml project data to the format in PEP 621 and (b) changing the backend to setuptools_scm instead of poetry.core. The former adds flexibility for different backends, and the latter allows removing all the version strings in the code and extracting version information from git tags.

Relevant SO question

I understand this is very much a matter of personal workflows and preference, so I don't want to take a strong position on the toml stuff. But definitely recommend discarding poetry.lock in the git repo to limit the dependabot.

[Jacob-Stevens-Haas]

Example of where setuptools_scm would be helpful:

git clone https://github.com/andgoldschmidt/derivative.git
cd derivative
pip install .
pip show derivative

gives:

Name: derivative
Version: 0.5.3
...

This means that I can't tell which actual revision is installed. If derivative were using setuptools_scm build backend, that version number would instead be 0.5.3.dev12+g04d5667.d20230414, which explains I'm on the 12th commit after version 0.5.3, commit hash 04d5667, with uncommitted changes from 2023-04-14.

This also means that if I have a local install of the current master branch (pip install <local_path_to_derivative) and I want to run tests on the PyPI version 0.5.3, if I uninstall derivative and try to reinstall with pip install derivative, pip will default to using the cached version of 0.5.3 that's actually the master branch, not the PyPI version (I think. still troubleshooting something atm). Since tests are passing on pysindy with my versions of installed packages but not on gh Actions, this would help me know where I should bump version requirements.

Related to #29

[andgoldschmidt]

I like a lot of these points, and appreciate the example. This reminds me that it'd be good to also have some CI attached to this project. My baseline package management strategy was to pick a tool that let me quickly ship, but I don't have any broader perspective or commitment to a certain workflow.

So, yes, it seems reasonable to migrate to an alternative. In the short term, I can ignore poetry.lock.