Remove caps for mamba & conda-build

[rohan-shah-nearmap]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

There is an issue in conda, only fixed in 23.7.0 which effectively prevents us from using recent package versions in our environments (earlier versions of conda have an incompatibility with recent versions of requests, see here). Unfortunately the current version of boa pins mamba <= 1.4.2, and then that version of mamba requires conda <= 23.4.

I can't really say that the current version of boa is compatible with updated mamba, but I have avoided the bug in 1.4.4. Hopefully someone else knows more.

Examples:

Cannot solve

FROM mambaorg/micromamba:jammy as build-stage

RUN micromamba create --dry-run --name boa --channel conda-forge \
    "python 3.10.*" \
    "boa >=0.15.1" \
    "conda >=23.7.1"

or

FROM mambaorg/micromamba:jammy as build-stage

RUN micromamba create --dry-run --name boa --channel conda-forge \
    "python 3.10.*" \
    "mamba 1.4.2" \
    "conda >=23.7.1"

But the following solves:

FROM mambaorg/micromamba:jammy as build-stage

RUN micromamba create --dry-run --name boa --channel conda-forge \
    "python 3.10.*" \
    "mamba 1.4.5" \
    "conda >=23.7.1"

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[rohan-shah-nearmap]

@conda-forge-admin, please rerender

[jaimergp]

@jakirkham @h-vetinari - this would unblock conda-forge/miniforge#480 but it might also be broken. Would love to have some extra eyeballs here.

[h-vetinari]

It's still capping conda-build, which will likely still cause other resolution oddities.

I don't know exactly what the problem was that led to the introduction of the cap(s), but it seemed it was something upstream (topological sort or so).

I did some digging in #75, but neither @wolfv nor @JohanMabille responded to my ping so far.

At this point, I'd be okay to just go for it and see what breaks. We already have breakage in some corners due to this version pile up anyway.

[h-vetinari]

Suggested change

	- conda-build >=3.24,<3.26
	- conda-build >=3.24

[victorlin]

Why unpin conda-build? This change is one of the causes for mamba-org/boa#388.

[h-vetinari]

Because that was a long-running effort to unblock many other things that required newer conda-build. The previous cap was there due to explicit incompatibilities, which were removed, hence the cap could be removed.

Now a new incompatibility got introduced with 3.28. It's a separate topic. The only take-away perhaps is to be more defensive on the pins here, and use <={last_working_conda_build}. In an ideal world that shouldn't be necessary (conda-build should deprecate behaviour changes, rather than just break things), but well...

[victorlin]

I see, thanks for clarifying.

Lately my practice has been to pin on major versions (i.e. conda-build >=3.24,<4) as those are likely to come with breaking changes. However, as we see in this case, there's still the possibility of breaking changes coming in minor version updates, which is unfortunate...

[h-vetinari]

Not everyone does versioning according to the server spec...

[wolfv]

I just tested and seems fine. I also made a PR to boa that fixes some deprecations: mamba-org/boa#367 Thanks everyone and sorry for being slow on this.

I think longer term that conda + conda-libmamba-solver + conda-build will be the better foundation for the "mambabuild" functionality :)

[jaimergp]

Unfortunately we are hitting some rough edges when the new build is in use. See conda-forge/staged-recipes#23923.

We'll need to mark as broken.