Usage numbers (per channel) of current/old client versions of conda etc. (from user-agent)

[mbargull]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

Make general usage numbers of different versions of conda, conda-libmamba-solver, libmambapy, mamba, etc. from https://conda.anaconda.org (https://repo.anaconda.com ?) available.
Ideally even separated per channel (e.g., for conda-forge, bioconda).

Data can be extracted from the (anonymized) user agent that conda & co. pass on to the servers (cf. conda info | grep -w user-agent).

Apart from the package managers' versions, base system (library) versions, e.g., glibc/2.17 (also reported in user agent string), could also be valuable.

Why is this needed?

With further adoptions of newer features/behaviors of more recent versions of conda & co. throughout the ecosystem, we have to take care that no sizeable portion of our users may be cut off due incompatibilities with outdated client versions that are still in use.
Being able to monitor the (change of) currently used client versions would give us a way the gauge the (inevitable) inertia in client version updates and schedule adoptions of features/changes accordingly.

Statistics of the aforementioned base system (library) versions, e.g., glibc, can be used as an indication on when/if the targeted system versions in our build systems could be raised.

What should happen?

Offer a (REST-) API endpoint or an aggregate à la https://github.com/ContinuumIO/anaconda-package-data that can be queried for usage numbers of conda (etc.) client versions for a given time.
Over the years these numbers have been previously provided from time to time/on demand (i.e., kindly via individual contacts at Anaconda), meaning with some manual (recurring) work required -- automating that process would/could be a welcome improvement.

(N.B.: With channel mirrors (existing onsite caches, HTTP or OCI mirrors, etc.), these numbers can be skewed a bit, but that is something that can be figured out downstream.)

Additional Context

Discussed in today's conda-forge/core meeting; ref: conda-forge/conda-forge.github.io#2267 .

cc @jezdez, @chenghlee, @jaimergp

[jaimergp]

@h-vetinari mentioned that with this data available we could have plots like those listed in https://mayeut.github.io/manylinux-timeline/

[h-vetinari]

Yeah, I was planning to raise this for conda-forge, but given how much is going on at the moment, I haven't taken the time to write this down yet.

The manylinux-timeline is obviously very focused on python-versions and on linux, we IMO don't need that level of detail necessarily, but what I'm interested in it (everything over time, in percentages of downloads relative to a suitable baseline):

• users per platforms (linux-64, etc.; probably needs some noarch special-casing)
• python versions (& implementations)
• glibc version
• macOS version
• windows version
• CUDA version
• conda version
• CPU arches
• etc.

Of course a dynamic dashboard would be the dream, but even just having static plots like manylinux would be a huge gain IMO.