build: use pyproject.toml to declare configs

[jsstevenson]

• incorporate build configs into pyproject.toml. This is the PyPA's recommended declaration model and lets you consolidate a couple of files and settings into one place.
• use setuptools-scm to define versioning. Rather than manually updating a version number in code (which can be easy to forget), you increment the version by making a new release on GitHub, and the package gets versioning from there. This is nice because it also automatically creates a changelog and static copies of released code. There are some good integrations from here as well.
• add a GitHub actions release workflow. This automates the twine/setuptools build process for uploading releases to PyPI, and is triggered on new GitHub releases. There's a small amount of setup to do on the PyPI side (I think it amounts to clicking a box once, @korikuzma would've done it most recently) but once it's ready, it just works and is super convenient.
• small precommit tweaks. update hooks version (silences a warning), pick a line ending standard, set a minimum precommit version.
• add some style and quality checks to GitHub Actions, which can run every time a PR is made or pushed to:
  • A stub that tests that the package installs properly. Next, I'd like to build this out into full fledged unit tests that can run in CI.
  • Style checks (black/flake8). If yall are up for it, I'd propose moving this over to Ruff in a future commit, it runs much faster (nice for local development) and can do a more expansive set of checks. I've actually learned a lot about modern Python features from Ruff's linting.
  • A subset of precommit checks. We've found that some less-regular contributors will forget to install precommit locally and will inadvertently introduce stuff like trailing whitespace or mixed line endings into the codebase, so it's nice to run these checks against incoming PRs.

[quinnwai]

Just minor comments. Checks on the PR and commit look good to me.

One question: could you do a random pypi release now to ensure that the setuptools-scm or whatnot works as expected? Or do we have to do this after this PR gets merged

[quinnwai]

preempted my thoughts here: would it be an easy win to add the current unit tests (pytest tests/unit) to the CI in this PR? Or were you considering it out of scope for the current PR

[jsstevenson]

I didn't think too hard about how nontrivial it would be to get these working, but I think there's still some configuration that would have to happen for the CI instance to be able to run them. Here's an example run trying every test: https://github.com/gks-anvil/vrs_anvil_toolkit/actions/runs/13637983594/job/38121227703

[quinnwai]

okay fair enough, we can make it out of scope then. I think the main problem is the supposed "unit tests" we created are pointing to an already downloaded seqrepo dir when testing occurs. Not sure how you do it in vrs-python but would be inclined to do it that same way.

[jsstevenson]

Ah yeah. For SeqRepo, we use the REST dataproxy in tests and then use something like pytest vcr to capture + stash the HTTP requests so that they can be used during CI/CD. It's a little painful but it works. I can make another issue to work that out.

[jsstevenson]

One question: could you do a random pypi release now to ensure that the setuptools-scm or whatnot works as expected? Or do we have to do this after this PR gets merged

Yeah good question @quinnwai . We've been using this exact workflow in all of our libs for a few years and it's held pretty steady, I took it straight from our template repo https://github.com/GenomicMedLab/software-templates/blob/main/python/%7B%7Bcookiecutter.project_slug%7D%7D/.github/workflows/release.yaml. See eg https://github.com/GenomicMedLab/cool-seq-tool/actions/workflows/release.yml

We can do a partial test right now. Just for kicks, I made a new release from the front of this branch. You can see progress here: https://github.com/gks-anvil/vrs_anvil_toolkit/actions/runs/13639823319. Basically, it builds successfully, but hits an error why submitting to PyPI because GitHub hasn't been added as a trusted publisher on the PyPI side yet.

Before it can completely run, someone with management access to the project on PyPI needs to do a few configurations: https://docs.pypi.org/trusted-publishers/adding-a-publisher/. We could briefly talk about this at the meeting tomorrow.

[quinnwai]

Awesome, created a trusted publisher and tested that the PyPi release works as expected. Ping me your username I can add you to the admin to the pypi as well

🚀