Action for periodic refresh of pixi.lock file? about pixi

[pavelzw]

Why you think that is the case?

At least the lockfile diff tool would be nice to be able to generate proper changelogs. Internally in our company, we have a tool to update lockfiles for conda which results in PR descriptions like this (see Quantco/multiregex#50):

It's not super pretty and maybe needs some formatting updates but if we decide to create something like this, I would like to have such changelogs in the PR descriptions.

[ruben-arts]

For Rust we often use cargo update and cargo upgrade. One updating the lockfile with current boundaries of the config file. And upgrade actually upgrading the boundaries as well. These are tools that I would love to see in pixi as well!

[pavelzw]

IMO as of now, until pixi supports update and upgrade, I don't think we should act. @Hofer-Julian could think about making his solution a reusable workflow that other repos can use.
If pixi had all tools available (i.e. lockfile diff, update/upgrade command), we could think about creating an official reusable workflow for this in the prefix-dev github namespace. (At least until there is proper dependabot/renovate support for pixi.)

But I don't think that this should be happening in prefix-dev/setup-pixi. Maybe something like prefix-dev/update-pixi-lockfiles.

[pavelzw]

I am not sure how to make CI run automatically on a PR create by an action, but that's another story

try using SSH deploy keys in combination with with: ssh-key: ${{ secrets.SSH_PRIVATE_KEY }} in actions/checkout, then the PR won't be opened by the github user who cannot trigger actions but instead by the person who added the deploy key. (at least this worked for me in some situations)

[pavelzw]

I think to do this properly, we would need a "lockfile diff tool" or pixi update (which supports json output that can tell you what exactly changed, xref #73 (comment)).

Ideally, imo, this behavior could be implemented in dependabot or renovate. I have heard there are some things happening on the renovate front with conda.

I am still a bit unsure what use cases such a tool should cover.

I think there are two main use cases:

Library

You develop a library and want to test against multiple versions (for example https://github.com/Quantco/polarify). There, the updater should come around occasionally and only update the upper bound if necessary. (you as maintainer should create necessary environments to properly test against all relevant versions).

Application

You develop an application and don't really care about supporting all versions of your dependency. There, the updater tool should come around occasionally and update both the upper bound and lower bound like dependabot for npm for example.

---

WDYT @0xbe7a @ruben-arts @wolfv @baszalmstra?

I'm also wondering how this is handled in languages with proper tooling such as rust.

I think #639 is also relevant for this issue.

[traversaro]

For Rust we often use cargo update and cargo upgrade. One updating the lockfile with current boundaries of the config file. And upgrade actually upgrading the boundaries as well. These are tools that I would love to see in pixi as well!

As linked by @pavelzw, the issue #73 is kind of related to that.

[traversaro]

I am not sure how to make CI run automatically on a PR create by an action, but that's another story

try using SSH deploy keys in combination with with: ssh-key: ${{ secrets.SSH_PRIVATE_KEY }} in actions/checkout, then the PR won't be opened by the github user who cannot trigger actions but instead by the person who added the deploy key. (at least this worked for me in some situations)

Cool, thanks!

[pavelzw]

@Hofer-Julian created a similar workflow in https://github.com/Deltares/iMOD-Documentation/blob/dd1c791944e1f513a8bd71a149b99e4a98e33a49/.github/workflows/pixi_auto_update.yml

[traversaro]

I think to do this properly, we would need a "lockfile diff tool" or pixi update (which supports json output that can tell you what exactly changed, xref prefix-dev/pixi#73 (comment)).

Why you think that is the case? If pixi.lock is unchanged, no PR will be opened as there is nothing to commit (that is already the default behavior of https://github.com/marketplace/actions/create-pull-request). By the way, thanks for linking #73, I remember something related but I could not find it.

I am still a bit unsure what use cases such a tool should cover.

It kind of covers the case in which you develop a library (so the first option), but you do not put upper bounds in the pixi.toml (almost only ="*"). I am not sure how niche is this user case is, but it is my use case at the moment. : ) If dependabot/renovate supported pixi.toml probably the need for having almost always ="*" would be reduced and hence the need of periodically refreshing pixi.lock without changing pixi.toml, but at the moment that is not the case.

@Hofer-Julian created a similar workflow in https://github.com/Deltares/iMOD-Documentation/blob/dd1c791944e1f513a8bd71a149b99e4a98e33a49/.github/workflows/pixi_auto_update.yml

That is exactly what I was looking for, thanks!

[Hofer-Julian]

I'm also wondering how this is handled in languages with proper tooling such as rust.

Most Rust projects that I know that have something like that use dependabot.
The supported update types are documented here: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore

[traversaro]

I see, thanks for the explanation.

[ruben-arts]

The lockfile diff tool is also a good idea!

[traversaro]

@Hofer-Julian created a similar workflow in https://github.com/Deltares/iMOD-Documentation/blob/dd1c791944e1f513a8bd71a149b99e4a98e33a49/.github/workflows/pixi_auto_update.yml

Just to have all aligned, at the moment by specific problem is solved by this. I think this may be a useful discussion, but anyhow I do not have need any specific change in setup-pixi in the short term. So, when you prefer feel free to close the issue, thanks!

[Hofer-Julian]

@Hofer-Julian could think about making his solution a reusable workflow that other repos can use.

I didn't know about reusable workflows. Will see if I can find time to set that up.

[pavelzw]

@ruben-arts can you transfer this issue into a prefix-dev/pixi discussion?