You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I feel like I'm missing something. Why would uv lock be called--because the version changed? PSR only builds the distribution artifact via the user configured build command and modifies files with a version number. Otherwise it does not handle any modification to your virtual environment (unless otherwise user-defined). PSR is also not designed to be aware of pip, uv or poetry or to interface them at all internally.
To solve this you can either modify the build command or add a step after to install the built distribution into your environment.
If you add some additional steps to your build_command configuration you can run whatever commands need to occur. But do note that the PSR GitHub action is a Docker action, meaning the build command is run inside of a container. uv is not installed in the container so if you need it, you need to make sure it's installed as one of the first steps of the build command. Yes, it's not intuitive and not ideal but that's the current situation for the docker action.
Thinking a little bit more about this. You need uv.lock updated because the next repo installation is broken because of mismatched files. So to solve this in your build_command you will need to run uv lock and add the lock file to the index.
Hi @codejedi365 many thanks; your swift solution worked like a charm! The uv.lock is now back in sync with the pyproject.toml when finishing the PSR github action.
Activity
codejedi365 commentedon Nov 13, 2024
I feel like I'm missing something. Why would
uv lockbe called--because the version changed? PSR only builds the distribution artifact via the user configured build command and modifies files with a version number. Otherwise it does not handle any modification to your virtual environment (unless otherwise user-defined). PSR is also not designed to be aware ofpip,uvorpoetryor to interface them at all internally.To solve this you can either modify the build command or add a step after to install the built distribution into your environment.
If you add some additional steps to your
build_commandconfiguration you can run whatever commands need to occur. But do note that the PSR GitHub action is a Docker action, meaning the build command is run inside of a container.uvis not installed in the container so if you need it, you need to make sure it's installed as one of the first steps of the build command. Yes, it's not intuitive and not ideal but that's the current situation for the docker action.codejedi365 commentedon Nov 13, 2024
Thinking a little bit more about this. You need
uv.lockupdated because the next repo installation is broken because of mismatched files. So to solve this in yourbuild_commandyou will need to runuv lockand add the lock file to the index.Because the file is added to the index during the build command, it will be included in the commit that is created by PSR.
Prior to the build command the repo files are stamped with the new version so when you run
uv lockin the build command it should update properly.aptly-io commentedon Nov 13, 2024
Hi @codejedi365 many thanks; your swift solution worked like a charm! The
uv.lockis now back in sync with thepyproject.tomlwhen finishing the PSR github action.codejedi365 commentedon Nov 13, 2024
@aptly-io, great to hear, thanks for replying and closing. Cheers!
beaugunderson commentedon Feb 13, 2025
This fixed our issue as well, we ended up using this
build_command; adding in cases it helps the next searcher: