Move away from poetry? about derivative

[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.