conda-forge / conda-forge/conda-forge.github.io
State of support for windows<10; how to specify lack of support for a given package
- Dominant language
- JavaScript
- Stars
- 170
- Forks
- 320
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 5
Description
AFAIU we don't actually capture the windows version of the user anywhere in the package metadata; i.e. `__win` has no value, and `conda info` on windows yields (for example):
```
virtual packages : __archspec=1=skylake
__conda=24.11.0=0
__win=0=0
```
It's not _completely_ lost, as it appears in the user-agent string for example, but I'm not aware this this is used anywhere, or indeed that it could be used for package metadata at all.
```
platform : win-64
user-agent : conda/24.11.0 requests/2.32.3 CPython/3.11.11 Windows/10 Windows/10.0.22631 solver/libmamba conda-libmamba-solver/24.11.1 libmambapy/2.0.4
^^ ^^^^^^^^^^
```
The trigger for opening this issue is stumbling over the boost 1.87 [release notes](https://www.boost.org/users/history/version_1_87_x.html), which state:
> [Filesystem](https://www.boost.org/libs/filesystem/):
>
> As was announced in 1.84.0, Windows versions prior to 10 are no longer supported.
Boost is not alone in starting to drop windows <10, and I suspect that our coverage of this is pretty bad, because the windows agents in CI are all obviously much newer already.
Our `ucrt` package [describes](https://github.com/conda-forge/ucrt-feedstock/blob/e34e36eccde18ea7b88a831a79e07c11e2f07c22/recipe/meta.yaml#L32) itself as "Redistributable files for Windows SDK. This is only needed Windows <10", so presumably we should still be broadly compatible (also because windows API is very stable).
However, this raises two immediate questions:
* how can we avoid that boost 1.87 gets installed on `win<10` systems?
* do we have an idea how wide-spread `win<10` still is among our users, and do we want to consider dropping support at some point?
Contributor guide
Assessment
This issue has not been assessed yet.