BUG: variant config key gets mis-converted from `10` to `1`

[h-vetinari]

In https://github.com/conda-forge/vc-feedstock/pull/79 we want to build:

  - name: vs_{{ cross_target_platform }}
    version: {{ vsyear }}.{{ update_version }}

However, this gets mis-transformed into:

BUILD START: ['vs2022_win-64-19.40.33808-hc77dda2_21.conda', 'vs_win-64-2022.1-hc77dda2_21.conda']
                                                                             ^
                                                                             should be 10

I've tried setting version: {{ vsyear }}.{{ update_version|int }}, but that doesn't change anything.

The logs show that the variable update_version definitely does get set to a string with the value '10':

channel_sources:
- conda-forge
channel_targets:
- conda-forge main
cl_version:
- 19.40.33808
cross_target_platform:
- win-arm64
docker_image:
- quay.io/condaforge/linux-anvil-cos7-x86_64
runtime_version:
- 14.40.33810
sha256:
- 15B8F5B2106DC7A7BD83AB57B796770E0F4ECB891AD19BF655C9D6A9DA650AD2
target_platform:
- win-arm64
update_version:
- '10'          <---------------------------------------------------------------
uuid:
- 1754ea58-11a6-44ab-a262-696e194ce543
vc:
- '14'
vcver:
- '14.3'
vsver:
- '17'
vsyear:
- '2022'
zip_keys:
- - vcver
  - vsyear
  - vsver
  - runtime_version
  - update_version
  - cl_version
  - uuid
  - sha256
  - cross_target_platform

Later this runs into predictable resolution errors (because apparently, the version constraint gets up correctly):

Solving environment (_test_env): ...working... failed
WARNING: failed to get package records, retrying.  exception was: Unsatisfiable dependencies for platform win-64: {MatchSpec("vs_win-64==2022.1=h753ab0a_21")}
Encountered problems while solving:
  - package vs2022_win-64-19.40.33808-h753ab0a_21 has constraint vs_win-64 2022.10 conflicting with vs_win-64-2022.1-h753ab0a_21

Could not solve for environment specs
The following packages are incompatible
├─ vs2022_win-64 19.40.33808.*  is installable and it requires
│  └─ vs_win-64 2022.10 , which can be installed;
└─ vs_win-64 2022.1.* h753ab0a_21 is not installable because it conflicts with any installable versions previously reported.

[mbargull]

Smells like there's some audit for YAML loading parts in order. Meaning, I'm pretty sure we'll find no conversion from 10 to 1 happening, but rather 2022.10 to 2022.1.

... And this is why I'm all the time stubbornly suggesting to always use https://yaml.org/spec/1.2.2/#101-failsafe-schema when reading YAML files and do all type conversions afterwards. (I.e., don't try to be clever and ultimately forget corner cases and/or create code smell.)

My take: Someone should review conda-build's code and ensure we always use BaseLoader (or equivalent -- that StringifyNumbersLoader doesn't count and should be removed and replaced by BaseLoader!). _{Don't try to convince me of any maybe-working midway solution -- you won't!}

[jaimergp]

In the meantime we could tell the linter to require quotes all the time (only half kidding).