feat: bump system requirements

[wolfv]

This PR bumps the system requirements to be more in line with current manylinux2_28 and minimum macOS versions.

While conda-forge is very conservative with the default system requirements, we can be a bit more bold. We based our first set of defaults on conda-forge defaults, but the aims are somewhat different: conda-forge tries to build packages for maximum compatibility while we are developing a software that is modern and probably mostly used on recent machines.

There is some pain with wheels that are only available for macOS 13.0+ which have become somewhat common on PyPI. Users would then receive sdists with all of their problems. Therefore I think it would be good to bump the minimum here. Users that want to support older systems or RedHat style Linux versions can always set different values in the pixi.toml.

[Hofer-Julian]

I feel like instead of bumping the default minimum system requirements from time to time we should instead make the system requirements required for the relevant platforms.

Then we bump the default system requirements of pixi init from time to time.

That way we only break once instead of small breaking changes for the rest of pixis life.

[baszalmstra]

I cant find the specific comment anymore but @ruben-arts proposed a method to dynamically determine system requirements when adding packages.

We should also record the system requirements in the lock-file to eliminate future issues.

[tdejager]

I cant find the specific comment anymore but @ruben-arts proposed a method to dynamically determine system requirements when adding packages.

We should also record the system requirements in the lock-file to eliminate future issues.

I feel the problem happens more often for pypi dependencies these days, these typically have higher system requirements then conda dependencies.

A solution for this would need to be found as well. Or we just go for @wolf or @Hofer-Julian ideas.

[Hofer-Julian]

I cant find the specific comment anymore but @ruben-arts proposed a method to dynamically determine system requirements when adding packages.

Assuming we are somewhat confident that we can implement this, but don't plan to do so soon, I would propose to go for @wolfv's approach for now. It should improve the UX for most people in the short term.

[baszalmstra]

Assuming we are somewhat confident that we can implement this, but don't plan to do so soon, I would propose to go for @wolfv's approach for now. It should improve the UX for most people in the short term.

Agree

[wolfv]

What's our conclusion for now?

• bump defaults, nothing further for now

Or

• bump defaults, but also record stuff in the lockfile

I would even go for the first option and make the other changes later on.

[baszalmstra]

IMO we can merge this PR now. Record in the lockfile later, and then add rubens idea after that.

[wolfv]

Then let me insta update

[tdejager]

Since everyone seems in agreement I'll approve.