Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move away from poetry? #27

Open
Jacob-Stevens-Haas opened this issue Apr 5, 2023 · 2 comments
Open

Move away from poetry? #27

Jacob-Stevens-Haas opened this issue Apr 5, 2023 · 2 comments

Comments

@Jacob-Stevens-Haas
Copy link
Collaborator

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
Copy link
Collaborator Author

Jacob-Stevens-Haas commented Apr 14, 2023

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants