Update CI dependencies

[ulgens]

I was planning to create a PR for Python 3.14 support but I realized that CI dependencies are outdated.

[dpranke]

Thanks for the PR! This seems fine assuming the CI jobs all still pass ... let's find out :).

[dpranke]

Oh, wait, I misread the diff ... the changes to ci.yml shouldn't cause or require the changes to uv.lock, right? Can we just change ci.yml and leave uv.lock unchanged?

If we need to update uv.lock as part of adding support for 3.14, let's do that in a separate PR (perhaps one of the others you've uploaded?), if we can.

revoking approval at least temporarily per my other comments ... I'll be happy to approve a revised patch.

[ulgens]

the changes to ci.yml shouldn't cause or require the changes to uv.lock, right?

Not a hard requirement and doesn't cause a failure but I'd still say "they kinda do". The reason I updated the lock file is that the new version of the uv uses revision 3, while the existing lock file is revision 1.

That being said, I can create a separate PR to update the lock file using the current uv version, then here in this PR lock again with the new uv version to this PR won't include any unrelated changes. It looks uv can't update the revision without running a full update.

[ulgens]

I just updated the PR to separate actual updates from the revision change. If the new versions looks better, I can separate the first commit into its own PR.

If it still feels noisy, I can create a PR for the uv update and separate that change from 3rd party action updates.

[dpranke]

I see. What version of uv are you using to generate the latest lock file?

Can we change pyproject.toml to use that version w/o triggering a bunch of other diffs and w/o dropping support for old versions (we might need to add version conditionals on uv to do that). It looks like the version in pyproject.toml is pretty old at this point (as presumably are the other versions, of course).

[ulgens]

Oh I completely missed the one in the pyproject.toml file. I was using 0.9.18, and considering this is a package and we won't want to pin to a patch version, I'd recommend going with >=0.9.0 because that's the first release with 3.14 support.

One question tho, why uv is needed as a project dependency? People will need the uv installed to be able to interact with those dependencies in the first place, so I'm missing where it will be used in the project itself. If the goal is to keep pyproject.toml and uv versions compatible, I'll recommend using required-version setting.

[dpranke]

uv isn't required; nor are any of the other packages in the dev set, really. However, specifying them helps ensure a fully reproducible environment. For the same reason, I prefer to always specify specific versions of each package in the pyproject.toml file, rather than simply specifying ranges as you suggest. Hopefully that makes sense?

I agree that we should probably add required-version as well.

[ulgens]

However, specifying them helps ensure a fully reproducible environment.

I support the intention, but this doesn't seem to work with uv. I tried to install an older version for #96 (comment) and it looks like the system's uv is still prioritized. Using a different version requires a different step - uv in the active venv is not used:

$ which python
[...]/open_source/pyjson5/.venv/bin/python
$ uv tree | grep uv
Resolved 55 packages in 17ms
└── uv v0.6.11 (extra: dev)
$ uv --version
uv 0.9.18 (Homebrew 2025-12-16)
$ uvx uv==0.6.11 --version
uv 0.6.11 (0632e24d1 2025-03-30)

[dpranke]

Interesting. I'll have to take a look later when I have more time to play with things. I'll assume you're right in the meantime :).

However, documenting which version of uv is actually used seems useful, and doing it here seems perhaps as good as anywhere else. Maybe add a comment that the version isn't actually used? Or even leave the version, but comment it out (along with a comment as to why it's commented out)?

I'm open to alternatives, too.

[dpranke]

whoops, ignore the "ready to review" bit, I hit the wrong button by mistake :).

[ulgens]

I think staying in the same revision should be enough to create reproducible builds/environments, and require-version helps with that. uv team's current method of saying "we changed something in the lock file format" is to increase the revision value. I'm not 100% sure that they won't change anything in the same revision that you would consider a hit to reproducibility, but coming with the experience with 20+ packages, I've never experienced this case being a problem.

[dpranke]

Good to know.

[dpranke]

Okay, playing with things a bit to follow up on your comment ... I was seeing the same thing with uv versions too, and was thoroughly befuddled until I dug into it.

I'm not sure what you were seeing, but I am guessing it was one of two things:

1. Unless you had actually activated the venv, running uv will (presumably) still pick up whatever your "system" uv is.

2. If you had activated the venv, but did that before running uv sync, then you might be getting hit by something else.

E.g., running on a Mac, using bash v5.3.9(1), I was seeing something like:

$ git clone https://github.com/dpranke/pyjson5
$ cd pyjson5
$ uv --version
uv 0.9.18 (Homebrew 2025-12-16)
$ uv venv
$ . .venv/bin/activate
$ which uv
/opt/homebrew/bin/uv
$ uv sync --extra dev
$ which uv
/Users/dpranke/Documents/src/pyjson5/.venv/bin/uv
$ uv --version
uv 0.9.18 (Homebrew 2025-12-16)
$ .venv/bin/uv --version
uv 0.6.11 (0632e24d1 2025-03-30)
$

Which made little sense to me. But, then I remembered that bash caches $PATH lookups, and so if you invoke a binary via the normal $PATH search (rather than specifying an explicit path), and then add a new binary somewhere in your $PATH before the directory containing the previous one, bash may not automatically see and use it.

You can check this with:

(in the same environment we left off ...)

$ type uv
uv is hashed (/opt/homebrew/bin/uv)
(pyjson5)
$ hash -r
$ uv --version
uv 0.6.11 (0632e24d1 2025-03-30)

So, once i fixed that, it seemed like I picked up the "correct" uv from the virtual environment.

Can you check to see if either of these things explains what you were seeing?

That said, learning more now, it does seem like using required-version would be a good idea. Maybe we should do that, and also pin the version of uv in the ci.yml file, but remove the package from pyproject.toml?

[ulgens]

So, once i fixed that, it seemed like I picked up the "correct" uv from the virtual environment.

I'm using zsh and testing the same steps

$ type uv
uv is /opt/homebrew/bin/uv
$ hash -r
$ type uv
uv is /opt/homebrew/bin/uv
$ uv --version
uv 0.9.18 (Homebrew 2025-12-16)

but they don't change the result.

---

That said, learning more now, it does seem like using required-version would be a good idea. Maybe we should do that, and also pin the version of uv in the ci.yml file, but remove the package from pyproject.toml?

All 👍🏻

Would you be interested in using the following pattern, so that Renovate can generate automatic dependency updates?

https://github.com/ulgens/django-blasphemy/blob/7dd9a7cd4a23aa0ddbc63ccc2be3fd0fd303c028/.github/workflows/tests.yml#L15

[dpranke]

Would you be interested in using the following pattern, so that Renovate can generate automatic dependency updates?

I'm not familiar w/ renovate (apart from what I've learned in looking at it just now). I had been thinking I needed to adopt something like dependabot, and it looks like renovate is similar, so, sure :). Do you have particular things you like about renovate more?

[dpranke]

I'm using zsh and testing the same steps

Hmm. And you're sure you activated the venv? I get the same thing in zsh 5.9 as I get in bash, except that after I've added uv to the venv and it should be getting picked up, I get just uv is /opt/homebrew/bin/uv from type uv; I don't get the "is hashed" part, although it looks like it is still being hashed and hash -r fixes it.

At any rate, I'm happy to move forward and remove the entry as discussed.

[ulgens]

I moved uv related changes to #100 and #101.

[dpranke]

Sorry for the delay :(. Looks good!

[ulgens]

@dpranke Coming from #96 (comment), Renovate does better what Dependabot claims it does.

• uv support just works fine.
  • Github's support is not there yet. There are multiple critical bugs with no resolution in the horizon: https://github.com/dependabot/dependabot-core/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22L%3A%20python%3Auv%22
• Supports pre-commit hooks.
  • It seems they put it on their calendar, Support pre-commit dependabot/dependabot-core#1524, but I wouldn't expect a working result in 2026. They tend to take their time with new ecosystems.
• It's more configurable and extendable.
  • I have a repo for the practices I consider "sane defaults": https://github.com/ulgens/renovate-presets

[dpranke]

I have a repo for the practices I consider "sane defaults": https://github.com/ulgens/renovate-presets

Cool, I'll take a look, thanks. I'm working on publishing a new version 0.13.0 with your changes and updated dependencies now.

[dpranke]

I'm working on publishing a new version 0.13.0 with your changes and updated dependencies now.

Published.