Libraries releases' version field description

[deathaxe]

With regards to

thecrawl/lib-spec.md

Lines 98 to 100 in a42b390

	`version` is usually `*` or omitted, t.i. we take the newest version that
	matches the asset pattern. You can restrict it using simple patterns, e.g. `5.*`
	or `4.1.*`, or full PEP 440 specifiers, e.g. `==3.2.2`, or `>=4.2.2,<5`.

Package Control 4 treats packages and libraries more or less equally with regards to meta data. This means the version key in a repository is dedicated to url based releases. It is not intented to be a PEP440 version specifier (e.g. >=1.0.0). It must not appear together with asset, base, tags or branch keys.

[kaste]

IIRC the version key here is an addition to the old implementation. repository.json has no entry with it atm.

[deathaxe]

Just saying it not being compliant with v4.0.0 schema and being actively rejected by PC4, should it ever see such a repository, in cases a user would add such to Package Control.sublime-settings.

It may not be that relevant in public infrastructure, though, as PC wouldn't fetch and handle repositories directly.

With regards to former ways to handle new features, it would mean to add a new schema version v4.1.0 and add support for version specifiers to PC4 as well - just in case.

P.S.: I see the idea and value behind this addition.

[kaste]

Back to this one. There are only a few changes -- or new features the crawler understands -- actually.

• You can specify version to a single version or a version spec. Examples: "1.2.1", "<2.0".

This is used internally for versioned PyPi URL's, like so:

{
  "base": "https://pypi.org/project/Markdown/3.2.2",
}

is translated, migrated to

{
  "base": "https://pypi.org/project/Markdown",
  "version": "3.2.2"
}

• You can drop the assets field, and let the crawler find suitable releases on its own.

This is just a simplification; which is probably very needed and helpful when the libraries run
through our main channel. How would braver otherwise review such changes. Example:

{
    "base": "https://pypi.org/project/lxml", 
}

This minimal description should resolve releases for our three (or six) platforms and three
python versions.

Ideally, the following minimal definition is sufficient and could replace the
current definition of lxml

{
  "name": "lxml",
  "releases": [
    {
        "base": "https://pypi.org/project/lxml"
    }
  ]
}

The idea is to use

$ uv run -m scripts.crawl_libraries --explain lxml
$ uv run -m scripts.crawl_libraries --name lxml

when trying such definitions. Maybe these modes can also be used for the automated
review for PR's.

• The metadata is fetched from the provider if not specified in the registry entry.

I think this is all opt-in.

--

Now that I made this, I see that -- for packages -- what we do with tags: <prefix>
could likely be solved using version as well. Easily more intuitive as
users would just make a new major version and tell the registry that e.g. <2
is for sublime_text < 4000.