Standardize pyproject and relax dependencies

[acmiyaguchi]

I'm working on trying to relax dependencies on a downstream library called pykoopman (https://github.com/dynamicslab/pykoopman) because it forces older versions of libraries like torch and scipy onto my project. There's a few transitive dependencies that I tracked here.

I ran the following:

uv venv
uv pip install -e .[dev,docs]
source .venv/bin/activate
pytest tests

This seems to work fine, so I think it might be favorable to relax dependencies until there are actual incompatibilities with upstream packages.

[acmiyaguchi]

Ah, it looks like there's some CI changes that need to be made too. I'll take a look into these.

[Jacob-Stevens-Haas]

Thanks for this work! It's a good change.

The general summary is see if it works to remove upper bounds but keep lower ones.

[acmiyaguchi]

Did some testing here with the matrix: https://github.com/acmiyaguchi/derivative/pull/1/checks. Just needed to bump the poetry version to pick up the new changes for pep 621 support. You're right that it's mostly the upper bounds on the packages/python that are causing issues, so I've added those back in.

[Jacob-Stevens-Haas]

LGTM, just a few things to do to make setuptools_scm work right:

• make version dynamic metadata
• make setuptools_scm write the version in the correct place
• Delete derivative/__version__.py and gitignore it.

[acmiyaguchi]

I imagine the version works via release tags? This seems to work locally, but I haven't used setuptools_scm before to know how it goes operationally.

$ uv build 
Building source distribution...
running egg_info
writing derivative.egg-info/PKG-INFO
[....]
adding 'derivative-0.1.dev184+g54753139b.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
Successfully built dist/derivative-0.1.dev184+g54753139b.tar.gz
Successfully built dist/derivative-0.1.dev184+g54753139b-py3-none-any.whl

[Jacob-Stevens-Haas]

Yes, exactly, it works via git and mercurial tags, then adds the number of commits, the current commit, and potentially a save date if there are uncommitted changes.

CI failures occur because accepting dynamic version metadata is optional and poetry has opted out. You can probably just rip out the poetry bit from CI and use pip to create the environment. If environment caching gives you trouble, it's probably fine to rip that out, too.

[acmiyaguchi]

@Jacob-Stevens-Haas sorry for the delay, this totally slipped my mind. Fwiw in my team at work we use https://github.com/mtkennerly/poetry-dynamic-versioning which seems to be the poetry equivalent to setuptools-scm.

Anyways I did some testing locally and uv build seems to work, and they also have a build in publishing mechanism, so I thought it'd be easier to drop this into CI. I can replace this with the vanilla equivalents (plus twine) if that's preferrable.

https://github.com/acmiyaguchi/derivative/actions/runs/18738960223 tests seem to go, I haven't tried docs or the publishing workflow, not sure what the best way to test those are on my end.

[Jacob-Stevens-Haas]

No worries, man, I'm just grateful for the PR. uv is fine. The one hiccup is the pull-docs.yaml workflow still invokes poetry run. You should just be able to use uv run -m. Or the command readthedocs uses, python -m sphinx build -T -b html docs docs/_build

@andgoldschmidt can you allow CI from forks in project settings? I don't think there's much a risk of malicious PRs using up the free CI allotment.

[andgoldschmidt]

@Jacob-Stevens-Haas The lowest tier was "new to github and first time contributor", which is now applied---we should be good with this, but let me know if not. Also added some missing basic branch protections.

@acmiyaguchi this is great, thanks for the contribution!

[Jacob-Stevens-Haas]

Great, LTGM!

[acmiyaguchi]

Thanks! Feel free to squash the changes if you decide to merge it in as-is, commit history always get iffy when mucking with CI.