Switch to uv to manage dev dependencies

[intgr]

What was done

I and @CodingWithSaksham adapted djangorestframework-stubs to the uv package manager, like django-stubs.

• Using build backend uv_build -- as opposed to hatchling which is used by django-stubs
• setup.py and setup.cfg migrated into pyproject.toml
  • Removed obsolete flake8 config.
• requirements.txt merged into pyproject.toml
• pytest.ini merged into pyproject.toml
• GitHub test.yml workflows
  • Using astral-sh/setup-uv@v6 to install uv & Python
  • Converted to use uv run & other uv commands.
  • New check to ensure uv.lock is up to date
• No longer depending on setuptools -- closes Update setuptools requirement from <79.0.0 to <81.0.0 #761

Related django-stubs PRs:

• Switch to pyproject.toml + PEP621 django-stubs#2688
• Use uv to manage dev dependencies django-stubs#2698

[intgr]

@UnknownPlatypus would you be interested in looking into this?

[UnknownPlatypus]

@intgr probably not until next week but I can have a look yes 👍

[CodingWithSaksham]

I can take a look after in October when I am free. I don't have much experience with uv though.

[CodingWithSaksham]

I have made progress with this but the tests keep failing. I have tried everything that I could. Here is a sample of the error code

E   pytest_mypy_plugins.utils.TypecheckAssertionError: Output is not expected: 
E   Actual:
E     main:1: error: Skipping analyzing "rest_framework.permissions": module is installed, but missing library stubs or py.typed marker  [import-untyped] (diff)
E     main:1: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports (diff)
E     main:2: error: Skipping analyzing "rest_framework.decorators": module is installed, but missing library stubs or py.typed marker  [import-untyped] (diff)
E     main:9: error: Unsupported operand type for ~ ("type[Permission]")  [operator] (diff)
E   Expected:
E     (empty)

Every test is giving nearly the same error but the line

E Actual:
E     main:1: error: Skipping analyzing "rest_framework.permissions": module is installed, but missing library stubs or py.typed marker  [import-untyped] (diff)

is repeated in every one, even though I have added a py.typed file in rest_framework-stubs directory.

I have configured pyproject.toml with this for mypy to use

[tool.mypy]
mypy_path = ["rest_framework-stubs"]
allow_redefinition = true
check_untyped_defs = true
incremental = true
strict_optional = false
show_traceback = true
warn_redundant_casts = true
warn_unused_configs = true
warn_unreachable = true
disallow_untyped_defs = true
namespace_packages = true
disable_error_code = "empty-body"
show_error_codes = false
plugins = ["mypy_django_plugin.main", "mypy_drf_plugin.main"]

Could you please guide me with this?

[intgr]

@CodingWithSaksham Thanks! Have you pushed the changes to some public branch where I could take a look?

I couldn't find it at https://github.com/CodingWithSaksham/djangorestframework-stubs/branches

[CodingWithSaksham]

Haven't pushed it yet! Will push it today for you to take a look at!

[CodingWithSaksham]

Pushed the code! @intgr
Here's the repo link!

https://github.com/CodingWithSaksham/djangorestframework-stubs/tree/use-uv

[intgr]

@CodingWithSaksham Thanks! I took your branch and managed to make it build successfully with some changes.

I lost track of exactly who made what changes, is it OK if I credit you with a Co-authored-by: commit message tag?

• Switching from hatchling build system to uv's own uv_build seemed to solve the main issue.
• Configuring mypy in pyproject.toml caused configuration to be ignored by pytest_mypy_plugins -- moved it back into mypy.ini for now. This migration can be done separately.
• Updated all dependency versions to match those in latest master branch.

[CodingWithSaksham]

I am absolutely fine with this! Thanks for the help!

[intgr]

--mypy-only-local-stub moved to pyproject.toml pytest config.

[Copilot]

Pull Request Overview

This PR migrates the djangorestframework-stubs project from using setuptools to the uv package manager for build and dependency management, following the same pattern applied to django-stubs.

Key changes:

• Adopts uv_build as the build backend instead of setuptools
• Consolidates configuration files into pyproject.toml
• Updates GitHub workflows to use uv commands throughout the CI pipeline

Reviewed Changes

Copilot reviewed 7 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
setup.py	Removes entire setuptools-based configuration file
setup.cfg	Removes flake8 configuration and metadata settings
pytest.ini	Removes pytest configuration (moved to pyproject.toml)
pyproject.toml	Adds comprehensive project configuration including dependencies, build settings, and tool configurations
CONTRIBUTING.md	Updates development setup instructions to use uv
.github/workflows/test.yml	Converts CI pipeline to use uv commands and setup-uv action
.editorconfig	Adds TOML file formatting configuration

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The mypy configuration reference should be updated to use pyproject.toml instead of mypy.ini since the project is consolidating configurations. Consider migrating mypy settings to [tool.mypy] in this file.

Suggested change

	"--mypy-only-local-stub",
	"--mypy-ini-file=mypy.ini"
	"--mypy-only-local-stub"

[intgr]

Migrating mypy.ini turned out to be problematic. Maybe later.

[CodingWithSaksham]

Did this previously, it made none of the tests pass. We need to approach this carefully then.

[CodingWithSaksham]

Updated my code to use uv-build instead of hatch and 29 out of the 36 test cases are failing!

Seems like pytest is unable to find

disable_error_code = ["empty-body"]
enable_error_code = ["ignore-without-code"]

when written in pyproject.toml

[intgr]

I removed py.typed file also. Stubs-only packages don't need to include py.typed. This file is meant for ordinary .py packages that already include embedded type hints.

[intgr]

One thing I realized is that uv.lock now also freezes the django-stubs repo commit & it won't update automatically. So this PR as-is would prevent finding out when django-stubs changes have broken djangofestframework-stubs. That would be bad.

Options:

1. Add uv lock --upgrade-package=django-stubs --upgrade-package=django-stubs-ext to workflows, which would restore the status quo: if a breaking django-stubs change is made, it will break our workflows without clear indication that was the cause. That was never ideal, this would be simplest for now.
2. Maybe teach @dependabot to update this. That would cause a lot of PRs & noise though, every time there's a commit to django-stubs. I would prefer not.
3. Ideally we would test every master build with latest django-stubs & only open a PR when breakage is detected. But I'm not sure how to set that up.

[CodingWithSaksham]

For the 3rd one, we could make a cron job or have django-stubs make a release webhook

The GitHub action will take the new django-stubs and run our tests against it, if it fails we can open a PR

[intgr]

I'm also a little hesitant about complex CI configurations; if something fails, debugging them can be a PITA. Perhaps there are more alternatives that I didn't consider.

[UnknownPlatypus]

Ideally we would test every master build with latest django-stubs & only open a PR when breakage is detected. But I'm not sure how to set that up.

We can install django-stubs@master in ci (I attempted that for mypy in django-stubs ) or could setup a daily ci job ( see this ruff daily fuzzing job for ex)

I think it depend on when you want to ensure latest django-stubs works. But I'm not a big fan of random ci jobs failing because it gives bad signals to contributors that have to understand it might not be their code the issue

[CodingWithSaksham]

I think it depend on when you want to ensure latest django-stubs works. But I'm not a big fan of random ci jobs failing because it gives bad signals to contributors that have to understand it might not be their code the issue

I completely agree with this! Even as a new contributor, I would hate to see a random documentation-only PR fail just because django-stubs released something that broke compatibility. That kind of noise can be discouraging.

In the end, whenever CI fails we really only have two options to check:

• Did the contributor’s change break it?

• Or did a new django-stubs release break it?

Maybe keeping it this simple is fine for now, rather than adding more complex CI logic that might be harder to debug.

[intgr]

One option would be to use Mend Renovate bot in the following way:

• Perform "lock file maintenance" periodically -- which updates all unlocked dependencies in uv.lock.
• Enable "auto-merge" -- it creates a branch, waits for branch CI to complete. If the CI succeeds, then it will auto-merge without a PR. It only opens a PR if the CI failed. This would prevent much of the "noise" aspect that I described.

Of course it's yet another tool to manage, but better than creating a custom workflow ourselves. I've been using it in multiple projects (open source & proprietary) and had good experience with it.

AFAIK @dependabot can't be configured to behave this way, but correct me if I'm wrong.

[intgr]

@sobolevn I've requested to enable the Renovate app in this repo.

[intgr]

Created PR for Renovate configuration:

• [INVALID] Configure Renovate to update uv.lock unpinned dependencies #832

[intgr]

I would like to merge this, but I haven't received any approvals.

The follow-up about updating unpinned dependencies will be dealt with in #832.

[UnknownPlatypus]

This is good for me, thanks for the work on this!

[sobolevn]

Done. https://developer.mend.io/github/typeddjango