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.

[pavelkomarov]

I would support moving away from poetry. It's awkward to have to poetry install the package to get this to register: [tool.poetry.plugins.'derivative.hyperparam_opt'] "kalman.default" = "derivative.utils:_default_kalman"

I'm currently having issues with poetry install --no-interaction -E dev, because it doesn't like that numpy doesn't support PEP517 or something.

[pavelkomarov]

Ah, nevermind. I can actually python3 -m pip install ., and then just python3 -m pytest -s, and the "kalman.default" is actually registered fine, and those tests no longer fail. So at least I can go on with development without poetry.

[acmiyaguchi]

#54 it's not a super big change to go from poetry into something more standard with setuptools. I think uv is starting to come into favor over poetry now, but either one supports the more generic pyproject standard via pep 621.

[Jacob-Stevens-Haas]

To clarify, this package uses poetry as build backend - I don't think uv aims to provide that, does it?

Ah, nevermind. I can actually python3 -m pip install ., and then just python3 -m pytest -s, and the "kalman.default" is actually registered fine, and those tests no longer fail. So at least I can go on with development without poetry.

In this case, pip is what's called an integration frontend and poetry is the build backend.

[acmiyaguchi]

uv does have a build backend that can generate eggs and wheels, and they have a nice lockfile implementation too. Regardless, I poetry 2.0 added a lot of nice ergonomics in the ability to deal with the standardized build configuration/