Write CEP about virtual packages #103

jaimergp · 2024-12-17T21:23:18Z

Motivated by this request: conda/conda#14443.

cep-????.md

jakirkham · 2024-12-17T22:29:06Z

cep-????.md

+- Python's `os.confstr("CS_GNU_LIBC_VERSION")`
+- `getconf GNU_LIBC_VERSION`
+- `ldd --version` (in GLIBC distros)
+- System's `libc.so` (in MUSL distros, location not standardized)


Think MUSL should be its own thing. It is versioned differently. Plus users presumably want to distinguish GLIBC built packages from MUSL ones

With the stdlib infrastructure, we have the technical requirements in place to do something like:

c_stdlib: # [linux] - sysroot # [linux] - musl # [linux] c_stdlib_version: # [linux] - 2.17 # [linux] - 1.2 # [linux] zip_keys: # [linux] - - c_stdlib # [linux] - c_stdlib_version # [linux]

Whether we want to roll out a "conda-forge for musl" is of course a separate question.

For the purpose of this CEP, definitely __glibc needs to stay musl-free IMO. For future-proofing, we could add __musl, but no strong feelings.

This is the GLIBC version in MUSL distros, not the MUSL version itself. Happy to adjust the wording though. See this block in the constructor SH templates for some more context.

Having glibc in musl is certainly not the default, I actually didn't know this is supported - TIL. In that case I agree it makes sense to report the glibc that's found.

So my point was that we could also build musl-native libs, but I guess that's much less urgent if alpine-users can just install a glibc compat (assuming this works with our glibc-flavoured packages).

Reading the original comment ( conda/constructor#850 (comment) ), think that user is referring to gcompat:

...a library which provides glibc-compatible APIs for use on musl libc systems.

While that can be useful, think we should not encode that in this CEP

It may make sense to have a CEP extending this for MUSL (perhaps including gcompat) and this could be one detail we include there, but would suggest we leave it out of this version and save it as future work

I think that user is referring to gcompat:

I'm not sure the original report was about gcompat, but about this alpine-focused glibc version.

The challenge is if we include this line (even as an example) future readers will look at this line and say "Hey that is how they said we should be supporting MUSL." Even if that is not what we meant. So taking this line out is safer than keep it IMO

The rest of the examples above seem fine

@jakirkham: think that user is referring to gcompat:

Look at the alpine wiki link I posted:

[wiki] If you want to run glibc programs in Alpine Linux, there are a few ways of doing so.

gcompat is one of them, but there are others.

@jakirkham: future readers will look at this line and say "Hey that is how they said we should be supporting MUSL."

I don't think that's realistic; it's also easy to preempt - just say "the version of glibc, if present (musl-based distros like alpine only provide this for compatibility; their main C library is musl itself)"

Sorry Axel think we had posted around the same time. Agree there can be other ways people try to handle this need

To loop back to Jaime's original point on how to word this, what if we just say the following

Suggested change

- System's `libc.so` (in MUSL distros, location not standardized)

- System's GNU `libc.so` (see specific disto for location)

Note: Some distros put libc.so in different places. So this is worth stating in its own right

I reworded these paragraphs a bit including the intent of the suggestions, let me know what you think!

cep-????.md

Co-authored-by: jakirkham <jakirkham@gmail.com>

cep-????.md

…ual-packages

jakirkham

Thanks Jaime! 🙏

Like the improvements and additions

Took another review pass with comments below

cep-????.md

baszalmstra · 2024-12-19T09:23:22Z

cep-????.md

+- Generic: `x86_64_v1`, `x86_64_v2`, `x86_64_v3`, `x86_64_v4`, `arm`, `ppc`...
+- Apple: For M1, the value is `m1`. M2 and M3 are reported as `m2` and `m3`, respectively.


Im not sure I understand this part. x86_64_v1, m1 etc are also part of archspec and are also properly detected as such.

I reworded this section a bit. Does that help? Otherwise I'll need more details to understand the question. Thanks!

cep-????.md

baszalmstra · 2024-12-19T09:25:55Z

cep-????.md

+This virtual package MUST be present when the system exhibits GPU drivers compatible with the CUDA runtimes. When available, the version value MUST be set to the oldest CUDA version supported by the detected drivers (i.e. the formatted value of `libcuda.cuDriverGetVersion()`), constrained to the first two components (major and minor) and formatted as `{major}.{minor}`. The build string MUST be `0`.
+


cuDriverGetVersion returns the version of the installed driver, not the oldest CUDA version supported by the detected drivers. Due to backwards compatibility support newer drivers also support older versions.

I think this returns the CUDA version as seen by the driver. The docs are not super clear. There's also cudaRuntimeGetVersionAt least this is what conda/conda uses.

@jakirkham could you help clarify this? Thanks!

But I think the driver CUDA version might not be the "oldest CUDA version supported by the detected driver". E.g. If my driver is 12.6 it might also support older CUDA versions.

Asking offline to see if others have thoughts here

That said, here are some rough thoughts. Starting with some background

When the CUDA Toolkit is typically shipped (like in the installer), it ships with a full suite of things including the driver library. However in Conda, we ship pretty much everything else except the driver library. So with Conda, the user is on the hook for ensuring the driver library is installed, which would happen when they install the driver

So this raises a question. How does Conda decide what version of the driver is compatible with a particular CUDA Toolkit?

This is what __cuda is solving. It is giving us the driver library's associated CUDA Toolkit version. IOW if that driver library was shipped in an installer, this is that installer's CUDA Toolkit version

So now when we try to install the CUDA Toolkit libraries, we can answer the question, will the driver be able to handle these?

Originally the answer was the CUDA Toolkit libraries we install could be no newer than the CUDA Toolkit the driver came from. We had checked this down to the major minor version (patch version was allowed to float). So if this driver check reported CUDA 10.1, we could only use CUDA Toolkit libraries from 10.1 or older. Eventually we relaxed this to major only for 11.2+ and 12

So really __cuda's version is the upper bound on the libraries we can use

Sorry for the long winded answer. Though hopefully the additional details provide context. Perhaps this can be incorporated into the text above somehow (after some discussion and Q&A)

Maybe something like this captures the idea above. Though please feel free to adjust further. Happy to look again after

Suggested change

This virtual package MUST be present when the system exhibits GPU drivers compatible with the CUDA runtimes. When available, the version value MUST be set to the oldest CUDA version supported by the detected drivers (i.e. the formatted value of `libcuda.cuDriverGetVersion()`), constrained to the first two components (major and minor) and formatted as `{major}.{minor}`. The build string MUST be `0`.

This virtual package MUST be present when the system exhibits NVIDIA GPU drivers compatible with the CUDA runtimes.

For systems without such support the virtual package MUST NOT be present.

When available, the version value MUST be set to the latest CUDA version supported by the detected drivers (i.e.

the formatted value of [`cuDriverGetVersion()`]( https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__VERSION.html )),

constrained to the first two components (major and minor) and formatted as `{major}.{minor}`. The build string MUST be `0`.

baszalmstra · 2024-12-19T09:29:56Z

cep-????.md

+
+The version MUST be overridable with the `CONDA_OVERRIDE_GLIBC` environment variable, if set to a non-empty value.
+
+If the GNU `libc` version could not be estimated (e.g. the tool is not running on Linux), the tool SHOULD provide a default value (e.g. `2.17`) and inform the user of that choice and its possible overrides; e.g. via `CONDA_OVERRIDE_GLIBC`, a CLI flag or a configuration file. The environment variable MUST be ignored when the target platform is not `linux~-*`.


Should there be a difference between gnu libc not being present and the version not being parsable? I think conda should also be able to run on systems without glibc if packages dont require it.

Maybe. What would be the expected behaviour? Something like this?

Not found: __glibc does not show up.

Not parsable: __glibc=0 + warning/advice to override.

I reworded this section a bit now so let's take another look.

cep-????.md

baszalmstra · 2024-12-19T09:32:41Z

cep-????.md

+
+#### `__win`
+
+This virtual package MUST be present when the target platform is `win-*`. The version MUST be set to the first three numeric components of the Windows build version, formatted as `{major}.{minor}.{build}`. If the version cannot be estimated (e.g. because the target platform does not match the native platform), the fallback value MUST be set to `0`. The build string MUST be `0`.


This is not currently the case for any installer (conda, mamba, pixi) right? I think all of them report __win=0=0 at the moment.

Im all for this change though!

Edit: mamba does seem to report the windows version properly:

> pixi exec mamba info ... virtual packages : __win=10.0.26100=0 > pixi exec conda info ... virtual packages : __win=0=0 > pixi info ... Virtual packages: __win=0=0

Exactly! This is what triggered the CEP: we will need to extend what mamba does to the full ecosystem soon due to some Windows deprecations in the boost library. See referenced issues in the text for more details.

Co-authored-by: jakirkham <jakirkham@gmail.com>

jaimergp · 2024-12-19T11:44:23Z

I reworked some sections:

__glibc only makes sense if native and target platforms match the same linux subdir, so now the text specifies the MUST clauses more strictly.
It makes no sense to override __unix or forcing its presence in non unix platforms, so this is now specified.
Removing (only some!) virtual packages by setting overrides to an empty string seems like a bad / useless idea. This will involve some fixes in conda/conda for sure, but we'll have a document now.
General considerations were reworded too for clarity.
Other suggestions from the code review.

isuruf · 2024-12-19T12:41:20Z

cep-????.md

+
+The build string MUST reflect one of:
+
+- The detected CPU microarchitecture when the target platform matches the native platform, as specified in the [`archspec/archspec-json` database](https://github.com/archspec/archspec-json/blob/v0.2.5/cpu/microarchitectures.json). For Apple Silicon, the reported values MUST correspond to the `vendor == Apple` entries; e.g. `m1`, `m2`, etc. For any other vendors, the reported values MUST correspond to the `vendor == generic` entries; e.g. `x86_64_v1`, `x86_64_v2`, `x86_64_v3`, `x86_64_v4`, `arm`, `ppc`, etc. 


Why should it correspond to vendor == generic? It's not the current behaviour in conda nor is it desired.

It's so far what I had observed in my Windows cloud machine, but maybe that's because archspec could not identify the actual CPU?

Reading the used function, that might be indeed the case.

Can we just say "whatever archspec.cpu.detect.host() does"?

Let me know if you find the latest edits acceptable 🙏

cep-????.md

jjhelmus · 2024-12-19T20:03:29Z

cep-????.md

+
+> The macOS version can be obtained via:
+> 
+> - Python's `platform.mac_ver()[0]`


This will return the SYSTEM_VERSION_COMPAT version if the Python interpreter running the command was built against the 10.15 SDK or earlier.

See https://eclecticlight.co/2020/08/13/macos-version-numbering-isnt-so-simple/ for details.

AFAICR, if you start the Python interpreter with SYSTEM_VERSION_COMPAT=0 it returns the 11.x based version, right?

Yes, running setting the environment variable will return a >=11 version.

My main concern here the "MUST NOT" language around the SYSTEM_VERSION_COMPAT workaround. I agree with the idea but this is not the case for the current version of conda (see conda/conda#13832). The example an this issue still reports a 10.16 version for __osx. Changing this to "SHOULD" would be reasonable, especially given that there are many releases of tools/packages that will report the compatible version that already exist.

I think we could consider that a bug in conda and submit a fix for 25.1 (as we are doing for __win). I can survey public repodata for __osx usage in the wild if that helps inform this decision.

See conda/conda@d94af02 (#14449)

jjhelmus · 2024-12-20T15:53:26Z

cep-????.md

+- `__unix`
+- `__win`
+
+#### `__archspec`


The microarch-level packages in conda-forge depend on __archspec to provide microarchitecture-level (e.g. x86-64-v2) meta-packages.

chenghlee · 2024-12-20T16:35:43Z

cep-????.md

+
+#### `__unix`
+
+This virtual package MUST be present when the target platform is `linux-*`, `osx-*` or `freebsd-*`. The version and build string fields MUST be set to `0`.


Rather than list the specific target platforms now and having to adjust this CEP if/when new platforms are adopted, I would suggest language like "when the target platform is sufficiently POSIX-y" and list the attributes necessary for that to be true (e.g., uses / for path delimiters, supports fork(3), etc.)

I agree with the sentiment, but I'm going to need some help or references to compile that list 😬

chenghlee · 2024-12-20T16:35:54Z

cep-????.md

+
+#### `__linux`
+
+This virtual package MUST be present when the target platform is `linux-*`. Its version value MUST be set to the Linux kernel version, constrained to the first two to four numeric components formatted as `{major}.{minor}.{micro}.{patch}`. If the version cannot be estimated (e.g. because the native platform is not Linux), the tool MUST set `version` to a fallback value of its choice. The build string MUST be `0`.


The Linux kernel upstream only defines {major}.{minor}.{micro}; anything beyond that (including the {patch} component you wrote) is part of the distribution kernel's version string. I don't think conda tooling should expose those components since their semantics of those will vary from distribution to distributon; e.g., patch 42 on Fedora may differ from patch 42 on Ubuntu.

Hm, this contradicts this comment in conda/conda. I'm happy to trim to three fields, but we'll need a source.

Ah ha! Since Linux 3.0, "[mainline] kernels with 3-part versions are -stable kernels"; however, the mainline 2.6 series had 4-part version numbers. The existing "3- or 4-part" comment in conda/conda comes from the fact that 2.6 is the upstream for the CentOS/RHEL 6 kernel, which was actively supported by Anaconda and conda-forge at the time I wrote that patch.

In light of that, I suggest replacing:

Its version value MUST be set to the Linux kernel version, constrained to the first two to four numeric components formatted as {major}.{minor}.{micro}.{patch}.

with something like:

Its version value MUST be set to the upstream (AKA mainline) Linux kernel version, but it MUST exclude any and all distribution-specific components of the kernel version.

I think that captures the intent of my previous comment, which was to ensure:

we don't allow conda packages to depend on [Linux] distribution-specific kernels via the __linux virtual package; and

we don't have to deal with the various ways Linux distros version their kernels (which may or may not be compatible with how conda does version ordering)

(That said, my suggested language does allow for non-release/development/-rcN kernels, but I suspect that user base is relatively small and able to cope if something goes horribly wrong.)

chenghlee · 2024-12-20T16:35:56Z

cep-????.md

+
+This virtual package MUST be present when the native and target platforms are both the same type of `linux-*` and GNU `libc` is installed in the system. The version value MUST be set to the system GNU `libc` version, constrained to the first two components (major and minor) formatted as `{major}.{minor}`. If the version cannot be estimated, the tool MUST set the version to a default value (e.g. `2.17`). 
+
+If the native platform does not match the target platform, the tool MAY export `__glibc` with its `version` field set to a default value (e.g. `2.17`) of its choice.  


Should we provide some guidance here on how the default value should be selected? If we don't, I could see situations arising where two different conda install tools or two different versions of the same install tool provide different default values on the same system.

conda/conda sets it to 2.5 (yes, I know).

Pixi chose 2.28.

Mamba skips it.

Rattler also skips the virtual package if a libc implementation cannot be found.

chenghlee · 2024-12-20T16:35:59Z

cep-????.md

+
+#### `__glibc`
+
+This virtual package MUST NOT be present if the target platform is not `linux-*`.


"...if the target platform's C standard library is not the GNU C Library". Not sure if we codify the assumption of all Linux systems inherently provide GNU libc or that only Linux uses GNU libc.

Current conda implementation assumes the latter "only Linux uses GNU libc". See https://github.com/conda/conda/blob/e74a2b9d8a74837afc3bcbef609fe4bd29572e16/conda/plugins/virtual_packages/linux.py#L14-L16.

If that's incorrect, (1) we need to fix that in conda/conda, and (2) I will update this paragraph.

chenghlee · 2024-12-20T16:36:03Z

cep-????.md

+- `__unix`
+- `__win`
+
+#### `__archspec`


Are we aware of any existing packages that actually depend on __archspec?

If not, I would rather we not make this virtual package mandatory at this time, mostly because "what microarchitecture is this CPU?" is a question that can get complicated quickly; see, e.g., ARM big.LITTLE, Intel P/E cores, Intel Xeon 6, etc. To me, this virtual package is still (pseudo-)experimental, in the sense that we still need to work out how package maintainers should/want to use this package. IMO, __archspec should be its own CEP or set of CEPs (cf. #59).

#103 (comment)

cep-????.md

baszalmstra · 2025-01-15T20:44:16Z

cep-????.md

+
+#### `__archspec`
+
+This virtual package MUST be always present, with the version set to `1`. 


Im wondering why this must always be present. For some target platform it doesnt seem to make sense (any platform where the archspec should be reported as 0 basically). Shouldn't we instead just omit the archspec in that case?

baszalmstra · 2025-01-15T20:54:05Z

cep-????.md

+
+- If the target platform matches the native platform, the best fitting CPU microarchitecture in the [`archspec/archspec-json` database](https://github.com/archspec/archspec-json/blob/v0.2.5/cpu/microarchitectures.json). The reference CPU detection implementation is [`archspec.cpu.detect.host()`](https://github.com/archspec/archspec/blob/v0.2.5/archspec/cpu/detect.py#L338).
+
+- The target platform architecture (second component of the platform string), mapped as: 


An interesting observation from this table is that there are a number of entries here that are not present in the archspec database (armv6l, armv7l, s390x, arm64) and are thus not actually existing microarchitectures. I guess we can make something up. But for arm64 I think it would be more appropriate to use aarch64 instead.

For rattler we have the following behavior:

win-arm64 -> aarch64
osx-arm64 -> m1

I think this makes sense because these are actual existing microarchitectures and they are also both the lowest possible supported microarchitectures on these platforms.

baszalmstra · 2025-01-15T20:54:35Z

cep-????.md

+  | `*-riscv64`     | `riscv64`                        |
+  | `*-s390x`       | `s390x`                          |
+  | `zos-z`         | `0`                              |
+  | Any other value | `0`                              |


Should riscv32 also be added?

Should we also add wasm32?

baszalmstra · 2025-01-15T20:58:57Z

cep-????.md

+This virtual package MUST be present when the system exhibits GPU drivers compatible with the CUDA runtimes. When available, the version value MUST be set to the oldest CUDA version supported by the detected drivers (i.e. the formatted value of `libcuda.cuDriverGetVersion()`), constrained to the first two components (major and minor) and formatted as `{major}.{minor}`. The build string MUST be `0`.
+


But I think the driver CUDA version might not be the "oldest CUDA version supported by the detected driver". E.g. If my driver is 12.6 it might also support older CUDA versions.

baszalmstra · 2025-01-15T21:06:10Z

cep-????.md

+
+This virtual package MUST be present when the native and target platforms are both the same type of `linux-*` and GNU `libc` is installed in the system. The version value MUST be set to the system GNU `libc` version, constrained to the first two components (major and minor) formatted as `{major}.{minor}`. If the version cannot be estimated, the tool MUST set the version to a default value (e.g. `2.17`). 
+
+If the native platform does not match the target platform, the tool MAY export `__glibc` with its `version` field set to a default value (e.g. `2.17`) of its choice.  


Rattler also skips the virtual package if a libc implementation cannot be found.

jaimergp added 4 commits December 17, 2024 22:22

Write CEP about virtual packages

ebcfa8e

Add some Windows methods

cda0a8c

some more

6f2d60f

add details of glibc, linux and osx

9a793b9

This was referenced Dec 17, 2024

Set __win version to platform.version when available, allowing overrides conda/conda#14450

Merged

ENH: make __win version usable for package metadata conda/conda#14443

Closed

pre-commit

9b4b7a7

jakirkham reviewed Dec 17, 2024

View reviewed changes

cep-????.md Show resolved Hide resolved

add discussion, implementation

59462ed

jaimergp mentioned this pull request Dec 17, 2024

Drop CONDA_OVERRIDE_WIN environment variable mamba-org/mamba#2815

Open

jakirkham reviewed Dec 17, 2024

View reviewed changes

cep-????.md Outdated Show resolved Hide resolved

jakirkham reviewed Dec 17, 2024

View reviewed changes

cep-????.md Outdated Show resolved Hide resolved

jakirkham reviewed Dec 17, 2024

View reviewed changes

cep-????.md Show resolved Hide resolved

jaimergp mentioned this pull request Dec 17, 2024

Could not find Windows version by calling 'ver' mamba-org/mamba#3359

Open

3 tasks

jaimergp and others added 2 commits December 17, 2024 23:48

add general paragraph about CONDA_OVERRIDE_*

cedde6a

Apply suggestions from code review

df9d61d

Co-authored-by: jakirkham <jakirkham@gmail.com>

jaimergp commented Dec 17, 2024

View reviewed changes

cep-????.md Outdated Show resolved Hide resolved

jaimergp added 3 commits December 18, 2024 00:43

more details about archspec

72022f4

Merge branch 'virtual-packages' of github.com:jaimergp/ceps into virt…

7c3b595

…ual-packages

link to existing issue

e6fcda5

jakirkham reviewed Dec 19, 2024

View reviewed changes

baszalmstra reviewed Dec 19, 2024

View reviewed changes

jaimergp and others added 7 commits December 19, 2024 11:35

Apply suggestions from code review

40b4442

Co-authored-by: jakirkham <jakirkham@gmail.com>

Move motivation further up

bc6d6a6

Rework __glibc specification

5bf10f1

Forbid CONDA_OVERRIDE_UNIX

7a2c7e5

format table

cd06910

Reword general considerations

e520336

Be stricter with override values and more lenient with fallback values

1b01182

traversaro mentioned this pull request Dec 19, 2024

DOC: Add documentation on CONDA_OVERRIDE_ARCHSPEC conda-forge/microarch-level-feedstock#14

Merged

4 tasks

reword __archspec

2148654

isuruf reviewed Dec 19, 2024

View reviewed changes

discard generic CPU rules

eaeb222

jjhelmus reviewed Dec 19, 2024

View reviewed changes

cep-????.md Show resolved Hide resolved

jjhelmus reviewed Dec 19, 2024

View reviewed changes

jaimergp mentioned this pull request Dec 20, 2024

Virtual packages fixes for __archspec, __osx and __linux conda/conda#14449

Merged

3 tasks

jjhelmus reviewed Dec 20, 2024

View reviewed changes

chenghlee reviewed Dec 20, 2024

View reviewed changes

clarify env var syntax

9a95c6b

baszalmstra mentioned this pull request Jan 15, 2025

feat: align with upcoming virtual package cep conda/rattler#1028

Merged

baszalmstra reviewed Jan 16, 2025

View reviewed changes

	- System's `libc.so` (in MUSL distros, location not standardized)
	- System's GNU `libc.so` (see specific disto for location)

		- Generic: `x86_64_v1`, `x86_64_v2`, `x86_64_v3`, `x86_64_v4`, `arm`, `ppc`...
		- Apple: For M1, the value is `m1`. M2 and M3 are reported as `m2` and `m3`, respectively.

		This virtual package MUST be present when the system exhibits GPU drivers compatible with the CUDA runtimes. When available, the version value MUST be set to the oldest CUDA version supported by the detected drivers (i.e. the formatted value of `libcuda.cuDriverGetVersion()`), constrained to the first two components (major and minor) and formatted as `{major}.{minor}`. The build string MUST be `0`.

-This virtual package MUST be present when the system exhibits GPU drivers compatible with the CUDA runtimes. When available, the version value MUST be set to the oldest CUDA version supported by the detected drivers (i.e. the formatted value of `libcuda.cuDriverGetVersion()`), constrained to the first two components (major and minor) and formatted as `{major}.{minor}`. The build string MUST be `0`.
+This virtual package MUST be present when the system exhibits NVIDIA GPU drivers compatible with the CUDA runtimes.
+For systems without such support the virtual package MUST NOT be present.
+When available, the version value MUST be set to the latest CUDA version supported by the detected drivers (i.e.
+the formatted value of [`cuDriverGetVersion()`]( https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__VERSION.html )),
+constrained to the first two components (major and minor) and formatted as `{major}.{minor}`. The build string MUST be `0`.


		The version MUST be overridable with the `CONDA_OVERRIDE_GLIBC` environment variable, if set to a non-empty value.

		If the GNU `libc` version could not be estimated (e.g. the tool is not running on Linux), the tool SHOULD provide a default value (e.g. `2.17`) and inform the user of that choice and its possible overrides; e.g. via `CONDA_OVERRIDE_GLIBC`, a CLI flag or a configuration file. The environment variable MUST be ignored when the target platform is not `linux~-*`.


		#### `__win`

		This virtual package MUST be present when the target platform is `win-*`. The version MUST be set to the first three numeric components of the Windows build version, formatted as `{major}.{minor}.{build}`. If the version cannot be estimated (e.g. because the target platform does not match the native platform), the fallback value MUST be set to `0`. The build string MUST be `0`.


		The build string MUST reflect one of:

		- The detected CPU microarchitecture when the target platform matches the native platform, as specified in the [`archspec/archspec-json` database](https://github.com/archspec/archspec-json/blob/v0.2.5/cpu/microarchitectures.json). For Apple Silicon, the reported values MUST correspond to the `vendor == Apple` entries; e.g. `m1`, `m2`, etc. For any other vendors, the reported values MUST correspond to the `vendor == generic` entries; e.g. `x86_64_v1`, `x86_64_v2`, `x86_64_v3`, `x86_64_v4`, `arm`, `ppc`, etc.


		#### `__unix`

		This virtual package MUST be present when the target platform is `linux-`, `osx-` or `freebsd-*`. The version and build string fields MUST be set to `0`.


		#### `__linux`

		This virtual package MUST be present when the target platform is `linux-*`. Its version value MUST be set to the Linux kernel version, constrained to the first two to four numeric components formatted as `{major}.{minor}.{micro}.{patch}`. If the version cannot be estimated (e.g. because the native platform is not Linux), the tool MUST set `version` to a fallback value of its choice. The build string MUST be `0`.


		This virtual package MUST be present when the native and target platforms are both the same type of `linux-*` and GNU `libc` is installed in the system. The version value MUST be set to the system GNU `libc` version, constrained to the first two components (major and minor) formatted as `{major}.{minor}`. If the version cannot be estimated, the tool MUST set the version to a default value (e.g. `2.17`).

		If the native platform does not match the target platform, the tool MAY export `__glibc` with its `version` field set to a default value (e.g. `2.17`) of its choice.


		#### `__glibc`

		This virtual package MUST NOT be present if the target platform is not `linux-*`.


		#### `__archspec`

		This virtual package MUST be always present, with the version set to `1`.


		- If the target platform matches the native platform, the best fitting CPU microarchitecture in the [`archspec/archspec-json` database](https://github.com/archspec/archspec-json/blob/v0.2.5/cpu/microarchitectures.json). The reference CPU detection implementation is [`archspec.cpu.detect.host()`](https://github.com/archspec/archspec/blob/v0.2.5/archspec/cpu/detect.py#L338).

		- The target platform architecture (second component of the platform string), mapped as:

Write CEP about virtual packages #103

Are you sure you want to change the base?

Write CEP about virtual packages #103

Conversation

jaimergp commented Dec 17, 2024

Choose a reason for hiding this comment

h-vetinari Dec 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakirkham Dec 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakirkham left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jaimergp commented Dec 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

h-vetinari Dec 17, 2024 •

edited

Loading

jakirkham Dec 17, 2024 •

edited

Loading