Run on --frozen to avoid locklfile update warnings

[ocefpaf]

@ChrisBarker-NOAA I decided to take a go here b/c the changes were a bit more involved if we want fast solves by eliminating the pypi install of xarray-subset-grid itself. While it is not a true PyPI access for it, the editable install in the previous configuration prevented us from using the fast pixi update --json --no-install.

The current configuration should be faster on all envs too.

[ChrisBarker-NOAA]

If I follow what the yaml file it doing, this looks great.

eliminating the pypi install of xarray-subset-grid itself.

yeah, I vacillate on that -- having an editable install as default seems to be "standard practice", but it's always seemed a bit off to me.

editable installs are for development, so what I"ve done is not put it in the default environment, and then have a dev environment that does include it.

and a "build" job that the tests can depend on for testing ... (really tests should be done on a proper install, not an editable install anyway)

[ocefpaf]

yeah, I vacillate on that -- having an editable install as default seems to be "standard practice", but it's always seemed a bit off to me.

There are many places where editable installs are OK and/or preferred, specially when mixing Python and non-Python packages. Python packaging has way too many ways to do this and that is the source of confusion IMO. We try to adapt as best as we can 😄

[ocefpaf]

@ChrisBarker-NOAA it turns out all we need to avoid getting 'out of sync' errors in the CIs was this option to run the frozen env. IMO, as long as we update the lockfile in some of our own PRs, we do not need the GHA to auto-update.

We can add renovate and let it auto-update instead, dependabot doesn't support it yet though. See dependabot/dependabot-core#2227

My concern here to main a GHA that may go stale quickly. What do you think? Let's remove the pixi-lockfile.yml file and wait for dependabot (or add renovate), or do nothing and update the lockfile when we want? I'm fine with any one of those options b/c they all reduce the amount of maintenance we need to do here.

[ocefpaf]

I'm convinced that we don't need the auto-update for the lockfiles. We can do that in PRs that will manually trigger this. The CIs won't complain about outdated lockfiles with the --frozen option.

PS: This one should be merged after #159.

[ChrisBarker-NOAA]

Sounds good to me -- merge away, when ready.

[ocefpaf]

Renamed the PR title b/c, in a way, we ended up solving this issue in different ways. We should still keep cache for multiple runs in the same PR, but we will get a refresh end when the commits/PRs are further apart in time.

Note that one can still have a pixi.lock locally, but we no longer commit it to the repo.

[ChrisBarker-NOAA]

Note that one can still have a pixi.lock locally, but we no longer commit it to the repo.

What's the logic here? -- sorry I lost track -- I think the pixi.lock file should be committed to the repo.

Then everywhere, everyone is using the same environment, and it only changes when it's changed on purpose.

However, as I write this, I realize there is a complication:

This is a library, not an application. So we want it to work with a range of dependency versions -- the obvious one is more than one version of Python, but then we also have a range of xarray versions, and who knows what else?

So locking it down with a lock file has downsides.

But I'm not really not sure how to handle that properly -- the matrix to test against is massive, so that's not an option.

(Though maybe, in this case, tests against a range of xarray versions, as well as Python versions?)

How DO people handle this?

One thought -- the development lockfile should probably use the oldest supported version of everything -- is there a way to tell pixi to do that?

[ocefpaf]

This is a library, not an application. So we want it to work with a range of dependency versions -- the obvious one is more than one version of Python, but then we also have a range of xarray versions, and who knows what else?

I'm not a fan of locking libraries beyond speeding up tests. also, this lockfile doesn't ensure that will happen b/c we do not package it or ask downstream users to use pixi. It was only for Cis.

So locking it down with a lock file has downsides.

But I'm not really not sure how to handle that properly -- the matrix to test against is massive, so that's not an option.

(Though maybe, in this case, tests against a range of xarray versions, as well as Python versions?)

How DO people handle this?

xarray is pretty stable. In fact, thanks to latest ABI3 improvements, even Python itself is getting more and more stable. I would not worry about this.

One thought -- the development lockfile should probably use the oldest supported version of everything -- is there a way to tell pixi to do that?

That is, in a way, what frozen does. It will only update when we want to, but that logic is not in the CIs. I don't think we need to though. We do want to catch deprecation warnings as the dependencies update.