commit pixi lockfile to git?

[ChrisBarker-NOAA]

I prefer to have the lockfile commited to git.

But this is a matter of some debate -- there's not one clearly bet way to do it.

Advantages:

• Everyone is working with the same config, which is nice.
• We don't all have to rebuild the lockfile ourselves when something changes.
• The CI is a bit more stable.

Disadvantages:

• The primary one I know of is that the project can get stale -- if no one runs an update, it can keep using ols version of deps for who knows how long, and you may no discover incompatibilities with newer package versions for a long while.

I think the best way to address that is to have a CI job run pixi update once in a while to keep things fresh.

But I don't want to make the change without some consensus.

This was discussed some in #107 -- but I don't think a consensus was reached.

@ocefpaf: you suggested that having the lockfile in git, with a CI job that updates it once in a while would defeat the purpose of the cache -- I don't thnk that's the case.

The idea is that the lockfile would be tested / updated in a separate job -- so a full set of tests would still be run with a single lockfile -- which would use the cache fine, wouldn't it? or maybe I misunderstand how the cache works.

[ocefpaf]

But I don't want to make the change without some consensus.

I don't have a strong opinion and I'm fine either way.

I think the best way to address that is to have a CI job run pixi update once in a while to keep things fresh.

That is possible. Something running every week or so would be fine.

@ocefpaf: you suggested that having the lockfile in git, with a CI job that updates it once in a while would defeat the purpose of the cache -- I don't thnk that's the case.

Indeed I thought so, but a CI cache is best used when we are working on a PR and it is re-used in the many commits to that same PR anyway. Anything 1 day apart is already "stale" in a PR context.

TL;DR I was being to conservative and a CI updating the lockfile is fine.

[ChrisBarker-NOAA]

Thanks -- I'll do that now.

I think it was particularly annoying at a stage when we were making a lot of changes fast.

[ChrisBarker-NOAA]

OK -- lockfie committed.

Now to the CI job -- I"m not entirely sure what should be done, but this looks like it may do the trick:

https://pixi.prefix.dev/dev/integration/ci/updates_github_actions/

Something like:

Periodically:

1. run pixi update and see if the lockfile changes.

• If it doesn't nothing to be done.
• If it does then:

2. run the tests with the new lockfile and see if anything breaks.

• If the test fail, then post a big warning somewhere (will gitHub email the maintainer when a test fails?)

• if the tests pass, then the options are:

a) do nothing -- report it somewhere ... an issue?
b) auto-push the new lockfile to the repo
c) open a PR to update the lockfile.

[ocefpaf]

If that opens a PR with the lockfile diff we will get testing and messaging already, right? Do you want to implement that or should I give it a go?

[ChrisBarker-NOAA]

looks like you've started: #9 -- thanks!