Using a jsonpath array filter with GenericToml extra-file config does not find the relevant version

[roberthjaplaio]

I have a python project managed with uv where I specify a build system in the pyproject.toml file. When I do this, my application is "installed" into the environment and I receive a version number into the uv.lock file.

While updating a lock file generally is perhaps not my best idea, I decided to try it out anyway using the generic toml updater but it seems I am unable to use a jsonpath filter. I have verified that the jsonpath works when I convert the toml to json, but to my surprise the release-please cli and the release please github action both log out that nothing was found in the uv.lock file. (No entries modified in $.package[?(@.name==="app")].version)

I have tried specifying an absolute path from the root of the project ("/uv.lock"). I have tried escaping double quotes as well as using single quotes, I've tried == and === but no success.

Example minimum uv.lock file to reproduce:

version = 1
requires-python = ">=3.13"

[[package]]
name = "app"
version = "3.1.0"
source = { virtual = "." }

Environment details

• OS: happens on OSX 15 and also the github action (v4)
• Node.js version: 23.4.0
• npm version: 10.9.2
• release-please version: 16.15.0

Steps to reproduce

1. using a release please config similar to this one:

{
"release-type": "python",
"packages": {
  ".": {
    "extra-files": [
      {
        "type": "toml",
        "path": "uv.lock",
        "jsonpath": "$.package[?(@.name==\"app\")].version"
      }
    ]
  }
}
}

Other attempted jsonpaths:

$.package[?(@.name==\"app\")].version
$.package[?(@.name=='app')].version
$.package[?(@.name===\"app\")].version
$.package[?(@.name==='app')].version

2. run release-please using cli or in a github action

I understand my problem could be avoided through various means and supporting updating a lock file like this makes no sense for release-please. However it seems that the generic toml updater might be broken because this file is a valid toml file and does not get updated.

[ClaytonJY]

I'm struggling with the same issue in trying to combine uv and release-please.

It's unfortunate uv records the version of editable dependencies in the lockfile, and that could change, but until it does I'm not sure how to workaround this.

My hope was to do as OP tried, using extra-files, but I'm having the same issue where it seems the full JSONPath specification might not be supported by release-please? If that's true, I think this should be reflected in the docs, which does not currently indicate any known restrictions.

Other approaches I can think of for uv + release-please:

1. use dynamic versioning with build-time hatchling hooks as recommended here. I haven't tried this, and I don't have any need for a built package (I'm shipping docker containers), so I don't want to introduce a build step, but seems like a nice solution when you're already building w/ hatchling
2. run uv sync in the same github workflow that runs release-please, committing the changed uv.lock to the same release branch created by release-please. I don't know for sure that this would work, but I think it should?
3. don't version the python package at all. Set version to something like 0.0.0, never update it. Use release-please to version the higher-level artifact, e.g. the tag on the docker container in my case. This seems pretty reasonable! Especially since there can be changes to the container unrelated to the python code, like changes to the Dockerfile. Why version both if I'm only shipping the container, right?

Option 3 is probably best for my use-case (only ship containers, not python packages), though I'll report back if it falls short. Curious to hear how others are working around this today.

[ClaytonJY]

I ended up doing option 2 instead, so I could have a good version available in my application for logging purposes. Was easy enough:

jobs:
  release-pr:
    name: Create Release PR
    runs-on: ubuntu-latest
    steps:
      - name: Create PR with release-please
        id: release-please
        uses: googleapis/release-please-action@v4
        # with:
          # will need a PAT to trigger checks from release-please PRs
          # https://github.com/googleapis/release-please-action?tab=readme-ov-file#github-credentials
          # token: ${{ secrets.MY_RELEASE_PLEASE_TOKEN }}

      # release-please is unable to update uv.lock, so we do it ourselves

      - name: Checkout release branch
        uses: actions/checkout@v4
        with:
          ref: ${{ fromJson(steps.release-please.outputs.pr).headBranchName }}

      - name: Setup `uv`
        uses: astral-sh/setup-uv@v5

      - name: Update `uv.lock`
        run: |
          uv lock
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add uv.lock
          git commit -m "ci: update uv.lock"
          git push

Still very interested to better understand the limits of JSONPath in release-please!

[yafanasiev]

I've hit the same issue and did a bit of digging, and luckily, found the culprit. Apparently, release-please parses TOML in a very weird way, so when I was expecting to be working with a JSON representation of uv.lock like this

  "package": [
    {
      "name": "aiohappyeyeballs",
      "version": "2.4.4",
      "wheels": [
        {
          "hash": "sha256:a980909d50efcd44795c4afeca523296716d50cd756ddca6af8c65b996e27de8",
          "size": 14756,
          "url": "https://files.pythonhosted.org/packages/b9/74/fbb6559de3607b3300b9be3cc64e97548d55678e44623db17820dbd20002/aiohappyeyeballs-2.4.4-py3-none-any.whl"
        }
      ],
      "sdist": {
        "hash": "sha256:5fdd7d87889c63183afc18ce9271f9b0a7d32c2303e394468dd45d514a757745",
        "size": 21977,
        "url": "https://files.pythonhosted.org/packages/7f/55/e4373e888fdacb15563ef6fa9fa8c8252476ea071e96fb46defac9f18bf2/aiohappyeyeballs-2.4.4.tar.gz"
      },
      "source": {
        "registry": "https://pypi.org/simple"
      }
    }
...
]

it is actually being parsed like this

  "package": [
    {
      "name": {
        "start": 455,
        "end": 473,
        "value": "aiohappyeyeballs"
      },
      "version": {
        "start": 484,
        "end": 491,
        "value": "2.4.4"
      },
      "source": {
        "registry": {
          "start": 514,
          "end": 539,
          "value": "https://pypi.org/simple"
        }
      },
      "sdist": {
        "url": {
          "start": 558,
          "end": 696,
          "value": "https://files.pythonhosted.org/packages/7f/55/e4373e888fdacb15563ef6fa9fa8c8252476ea071e96fb46defac9f18bf2/aiohappyeyeballs-2.4.4.tar.gz"
        },
        "hash": {
          "start": 705,
          "end": 778,
          "value": "sha256:5fdd7d87889c63183afc18ce9271f9b0a7d32c2303e394468dd45d514a757745"
        },
        "size": 21977
      },
      "wheels": [
        {
          "url": {
            "start": 818,
            "end": 966,
            "value": "https://files.pythonhosted.org/packages/b9/74/fbb6559de3607b3300b9be3cc64e97548d55678e44623db17820dbd20002/aiohappyeyeballs-2.4.4-py3-none-any.whl"
          },
          "hash": {
            "start": 975,
            "end": 1048,
            "value": "sha256:a980909d50efcd44795c4afeca523296716d50cd756ddca6af8c65b996e27de8"
          },
          "size": 14756
        }
      ]
    }
...
]

So you would think that the correct JSONPath now is $.package[?(@.name.value=='aiohappyeyeballs')].version.value, and it will actually select a version number... but now it will fail to update the JSON because when updating, it mow works with proper JSON representation 😢
So the final working solution is $.package[?(@.name.value=='aiohappyeyeballs')].version, which selects (technically incorrectly) object instead of string value, but will result in a proper update.

The root cause is buried somewhere in here, hopefully this could be fixed sometime in the future.

cc @ClaytonJY @roberthjaplaio