uv/tests: add new 'ecosystem' integration tests #5970
Conversation
|
Could we note in a README or something what commits these were pulled from for each project? |
BurntSushi
force-pushed
the
ag/ecosystem
branch
3 times, most recently
from
26f93b1 to
8f662eb
Compare
|
I marked the |
BurntSushi
force-pushed
the
ag/ecosystem
branch
from
87e49d2 to
710bb11
Compare
|
I love having ecosystem test for the universal resolver! Are there options to trim them down? 30k lines is a lot. |
|
Alternatively, we could have them in a separate repository and test them in a separate workflow than |
I can't think of one. You could compress them, but then you inhibit human readability. @zanieb I'm not a huge fan of having them in a separate repo if we can avoid it, mostly because I think it's a big pain to have tests hosted elsewhere. Then any updates need multiple PRs. And we're already doing that for packse scenarios. |
BurntSushi
force-pushed
the
ag/ecosystem
branch
3 times, most recently
from
f45f561 to
e5dff68
Compare
We're going to want to use this in other places, so move it to 'common'. Since it isn't used in all test modules, we do need to squash unused lint warnings unfortunately.
This adds a new top-level directory with bare-bones directories for a sampling of ecosystem projects. The idea is for each directory to have enough that `uv lock` can run. The point of these tests is to 1) ensure resolution works in common cases and 2) track changes to resolutions (and the lock file) in real world projects. Unfortunately, it does look like in some cases, re-running `uv lock` results in changes to the lock file. For those cases, I've disabled the deterministic checking in exchange for getting the lock files tracked in tests. I haven't investigated yet whether either of #5733 or #5887 fix the deterministic problem. There is probably a better way to go about integrating ecosystem projects. In particular, it would be really nice if there was a good flow for upgrading ecosystem packages to their latest version. The main complexity is that some projects require edits to their `pyproject.toml` (or a complete migration from non-`pyproject.toml` to `pyproject.toml`). Although, the projects added here in this initial set were limited to those that didn't require any changes.
There are some epic simplifications here.
It takes too long otherwise. ¯\_(ツ)_/¯
So that we're a bit more dynamic about whether we run them or not.
BurntSushi
force-pushed
the
ag/ecosystem
branch
from
e5dff68 to
baf23f4
Compare
I didn't mean to commit these in #5970.
I didn't mean to commit these in #5970.
At a high level, this PR adds a smattering of new tests that
effectively snapshot the output of
uv lockfor a selection of"ecosystem" projects. That is, real Python projects for which we expect
uvto work well with.The main idea with these tests is to get a better idea of how changes
in
uvimpact the lock files of real world projects. For example,we're hoping that these tests will help give us data for how #5733
differs from #5887.
This has already revealed some bugs. Namely, re-running
uv lockfor asecond time will produce a different lock file for some projects. So to
prioritize getting the tests added, for those projects, we don't do the
deterministic checking.