Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
roberthjaplaio opened this issue Dec 18, 2024 · 2 comments
Assignees
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@roberthjaplaio
Copy link

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
  1. 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.

@roberthjaplaio roberthjaplaio added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Dec 18, 2024
@ClaytonJY
Copy link

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
Copy link

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!

@meltsufin meltsufin added priority: p3 Desirable enhancement or fix. May not be included in next release. and removed priority: p2 Moderately-important priority. Fix may not be included in next release. labels Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

No branches or pull requests

4 participants