switch to uv, and modernize CI yaml

[Light2Dark]

Summary

• Switch dependency management from pip to uv. uv is way faster and simpler to set up.
• Rework CI into three jobs — lint, test, and integration — using a shared composite setup action (setup-uv, uv sync --frozen)
• Expand the test matrix from Python 3.13 only to 3.10–3.14, and run unit tests separately from integration tests (integration only runs when Drive credentials are available: pushes to master, same-repo PRs, or manual dispatch). Integration tests atm only run on 3.13, maybe we can expand in the future.
• Modernize pyproject.toml license metadata (BSD-3-Clause + license-files)

[martindurant]

I don't mind to use uv, but I am surprised you say it is "faster" - isn't the install part of the CI run an insignificant part of total in either case? Sticking with the standard would be simpler.

[martindurant]

Expand the test matrix from Python 3.13 only to 3.10–3.14

Do you find this works? I would worry about parallel access to the same drive and the weird races this can cause. Every test run had better at least run with a unique prefix and be sure to clean it up.

[Light2Dark]

I don't mind to use uv, but I am surprised you say it is "faster"

Yeah, you're probably right. I did not benchmark this. For a repo of this size, I don't think it matters. I'm used to uv being faster on my other projects hence the statement.

To offer some reasons why to use uv:

• Easier migration story now than in the future
• There's a few small things that make uv really nice to develop in. For example, I added a dev dependency group, to install on pip, you'd have to run pip install --group dev --editable .. For uv, it's just uv sync.
• Introduce the lockfile. Can do this with pip too, but this comes nicely built in with uv. We'd be able to lock CI tests from failing in the future if some upstream deps change.

Do you find this works? I would worry about parallel access to the same drive and the weird races this can cause.

I've only expanded the Python matrix for unit tests which doesn't access a real drive, and run fully isolated.
For integration test (the one against the live drive), it runs on python 3.13. Mainly because I felt it was an 'expensive' test, so limit it.

[martindurant]

We'd be able to lock CI tests from failing in the future if some upstream deps change.

I'm actually against this - we want the CI to fail if a dep breaks current code. Otherwise we wouldn't be aware of real failing installations that users might be experiencing.

[Light2Dark]

We'd be able to lock CI tests from failing in the future if some upstream deps change.

I'm actually against this - we want the CI to fail if a dep breaks current code. Otherwise we wouldn't be aware of real failing installations that users might be experiencing.

Yeah that makes sense, I should be more careful. I can remove the lockfile and the CI that generates it.

Are you still keen on using uv? Or stick to pip

[martindurant]

Are you still keen on using uv? Or stick to pip

I don't mind uv, but it would put more responsibility on you, since I barely use it myself.

[Light2Dark]

done! cleaner now

[Light2Dark]

This was a deprecated license spec and hence raised errors when resolving uv.
https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license

SetuptoolsDeprecationWarning: License classifiers are deprecated.
!!

        ********************************************************************************
        Please consider removing the following classifiers in favor of a SPDX license expression:

        License :: OSI Approved :: BSD License

        See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.

[Light2Dark]

Added because of

  self._finalize_license_expression()
error: Multiple top-level packages discovered in a flat-layout: ['tmp', 'gdrive_fsspec'].

To avoid accidental inclusion of unwanted files or directories,
setuptools will not proceed with this build.

If you are trying to create a single distribution with multiple packages
on purpose, you should not rely on automatic discovery.
Instead, consider the following options:

1. set up custom discovery (`find` directive with `include` or `exclude`)
2. use a `src-layout`
3. explicitly set `py_modules` or `packages` with a list of names

To find more information, look for "package discovery" on setuptools docs.