What is the plan for migrating the win-64 builds to vs2022?

[jdblischak]

Your question:

Motivation

The next release of tiledb-feedstock will require us to use vs2022 for its win-64 build. Manually migrating a single feedstock to vs2022 is straightforward and well documented. However, it's my understanding that after we build with vs2022, all downstream conda-forge packages that depend on tiledb will also be required to migrate to vs2022 (and thus their dependencies and beyond throughout the dependency network). Thus I was curious: is their a plan/timeline for migrating the conda-forge win-64 builds to vs2022?

xref: TileDB-Inc/conda-forge-nightly-controller#69, conda-forge/tiledb-feedstock#268

Research

• Move to vc142 toolchain on windows #1732 - proposed the migration to vs2019. Also noted "The one caveat is that any library built with a given toolset version can only be consumed (e.g. linked) by a toolset version that's the same or newer."

• move to vs2019/vc142 conda-forge-pinning-feedstock#3167 - This is the PR that bumped the pin from vs2017 to vs2019

• vs2022 for win-arm64 conda-forge-pinning-feedstock#4415 - The PR title says it all

• Update maintainer kb windows doc #1956 (comment) - This comment from @h-vetinari nicely summarizes the current practice of conda-forge to be conservative when it comes to updating MSVC

[h-vetinari]

From my personal POV, I don't mind moving on, especially as it does not affect the vast majority of users that are just downloading packages, only someone doing local development against old VS versions (which are also easy to upgrade, and I haven't heard from anyone who got stuck in this situation during the move to VS2019 for example).

That said, #1732 was strongly motivated by CI providers dropping support for VS2017, key upstream projects starting to require VS2019, and substantial bitrot in VS2017 support even where nominally still compatible. We're not yet at that point with VS2019 by far.

Then again, VS2019 will reach EOL in ~2 weeks, so it's quite possible that a similar chain of events will happen in the coming months as for VS2017->VS2019.

In the case of tiledb, it's worth keeping in mind that there's no hard rule about individual feedstocks updating their compiler stack (despite the viral requirement that consumers that compile against outputs of said feedstock also need to update). In particular, the set of (transitive) compile-dependents of tiledb is small compared to the rest of conda-forge. Where that question becomes harder is if a really widespread package needs a newer compiler stack, but so far I don't think such a situation has arisen yet.

[h-vetinari]

Google just dropped support for VS2019 going forward - that means upcoming abseil/grpc/protobuf etc. (and their dependents) will very likely need to move.

[jdblischak]

the viral requirement that consumers that compile against outputs of said feedstock also need to update

@h-vetinari we have reached this point with TileDB, though it isn't going as we expected.

• TileDB 2.22 was compiled with cxx_compiler: vs2022 and c_stdlib_version: 2022 (tiledb v2.22.0 tiledb-feedstock#275)

https://github.com/conda-forge/tiledb-feedstock/blob/01cf999bc377665d5b763ed9506f14b334a0b28b/recipe/conda_build_config.yaml#L1-L4

• The recent migration of gdal-feedstock to TileDB 2.22 continued to use cxx_compiler: vs2019 and also didn't set c_stdlib_version: 2022 (Rebuild for tiledb 2.22 gdal-feedstock#913). But surprisingly the build passed

https://github.com/conda-forge/gdal-feedstock/pull/913/files#diff-283d4846cd6e9d12c8444a622943204d7a168d0c8c350127106345fd3f42ac2b

Which leads me to the following questions:

1. Why didn't the build fail? Is there a test we could add to the recipe to catch this discrepancy?
2. Is there any way to automate the propagation of the cxx_compiler and c_stdlib_version pins, e.g. via "run exports" or conda smithy rerender?

[h-vetinari]

Why didn't the build fail? Is there a test we could add to the recipe to catch this discrepancy?

It's not a guarantee that things break; for example, if the artefact produced by VS2022 uses no features not supported by VS2019, things should work.

I'd say it's the other way around. If a consumer of a package built by VS2022 can still compile with VS2019, that's no problem, but if anything breaks, just upgrade that feedstock.