idea: versionable keys

[jhheider]

Over time, this will become important if we don't want to fracture the package.yml; indeed, it would have been useful for pcre.org, due to "v2" being >=10. In theory it could support pretty much any key sequence, but you might expect:

provides:
  <1.69.0: [rustdoc, rustc, clippy, rustlsp]
  ^1.69: [rustc, clippy, rust-analyzer]

build:
  dependencies:
    ^1: { gnu.org/glibc: ^2 }
    '>=2': { github.com/besser82/libxcrypt: '*' }
  script:
    ^8: |
      ./configure
      make install
    '>=9': cargo install --path . [..]

Etc. I think the idea is clear. It's just... very complicated. You'd basically need to check every key in the yaml to see if it was keyed by semver.Range.

This is an alternate to a slightly sloppier idea, in which project directories could include package.${semver.Range}.yml, allowing the system to match out the package.yml for its proposed version.

Both of these ideas have glaring issues for version resolution: they complicate the resolution algorithm, since resolving pcre.org: '*' is equivalent to a dependency on pcre.org: <10 || pcre.org: >=10, and we don't yet have resolution for alternate package dependencies in this way.

[mxcl]

I originally thought we'd do versioned keys. But over time have realized some duplication is ok and lean towards separate files.

Do we have an example yet other that pcre where we need this sort of thing?

[jhheider]

Haskell.org would be one. Possibly yarn/berry. Certainly glib2 changing pcre deps in a patch release. Anything that uses semverator to behave differently for different versions, like rust, python, etc.

[mxcl]

We've managed to workaround all these so far.

I think a notable one is python/pip where we cannot use python before 3.7 because pip has a dep on ^3.7.

Though this really only effects those who want python 2, which is more people than you'd think.

So in that case we need some mechanism and versioned keys seems cleaner. How else would you even represent it? especially considering provides and version look ups from tea/cli.

So yeah versioned keys seems necessary and then we can fix pcre

[mxcl]

possibly we wouldn't fix pcre. Maybe the rule is: versioning for the same provides. and presuming we will do provides for lib/libbasename at some point that would make it so pcre needs a split.

[jhheider]

PCRE is a weirdo, as is yarn/berry. But python/pip, and probably other languages with their companions are likely candidates.

The real pain is entirely different build scripts. I assume, say, Haskell 7 would require a package.yml that different in nearly every particular from the current.