Add support for releases with "asset" patterns

[deathaxe]

To support packages which need an active build step, Package Control 4 supports github releases, additionally to "branches" and "tags".

It therefore supports an additional "asset" key, which is a pattern to select desired download asset from Github releases. Each release may contain multiple package variants targetting different ST builds.

It can also be used to replace prefixed tags as packages targetting different versions of ST can be grouped under a single semver tag.

Example: https://github.com/SublimeText/Liquid/releases/tag/4149-2.3.0

Another prominent use case are dependencies, which should use this strategy to be deployed as WHEEL files, ideally.

Example:

• repository https://github.com/packagecontrol/sublime_aio/releases/tag/v0.1.5
• channel: https://github.com/packagecontrol/channel/blob/026d99415281e1571063e2a6dc665800947f433c/repository.json#L1997-L2009

Effectively there are only few ST4-only dependencies, which can't/shouldn't be deployed via PyPI: lsp_utils, mdpopups, sublime_lib, sublime_aio, all of which would ideally switch to asset based releases so we can drop legacy dependency support from Package Control client.

The crawler needs to learn to resolve asset based releases to effectivly be able to switch to package_control_channel/four-point-oh branch and use it as THE new default under https://github.com/packagecontrol/channel.

It also requires the crawler to learn PyPI for continued support of Package Control 4.2.0, which won't get logic to resolve python packagtes directly.

[kaste]

The only reason that this is not done "first" is that I never wanted to break the "official" crawler (yet?). Hence we can't merge anything into the main channel that would break the old crawler. That would be rude when sublimhq still says that they get this resolved. 2028 maybe? I don't understand what package_control_channel vs packagecontrol/channel would mean, I also don't know what sublimehq wants to claim and why they're not able to sign and host a PC zip file. Maybe we're at schema_version 4.5 then, maybe I already retired. That is really (for me) like corporate, politics stuff. You did 4.0 and still wait for a deploy (since when ... 3 years?).

[deathaxe]

And here are the subtile agressive attacks again, just because you completely missing the point!

[deathaxe]

The main point is just to bring thecrawl features inline with those of package_control v4, even if it never arrived in packagecontrol.io unfortunatelly.

My primary concerns with the old channel however are, that any change is likely to break the old crawler and we don't know which ones are biting it. We can't do required cleanups without risk of breaking it.

With Package Control using the new channel and packages.sublimetext.io being online, the old site is expected to fade out.

The crawler needs to learn to resolve asset based releases to effectivly be able to switch to package_control_channel/four-point-oh branch and use it as THE new default under https://github.com/packagecontrol/channel.

What's so hard about understand this?

1. Move package_control_channel/four-point-oh to packagecontrol/channel
2. use it as only/primary source for thecrawl

I want to get rid of the extra-library crawler and the extra complexity needed to merge different channels in a post-processing steps. One channel, one crawler, one site.

For the time being normal packages can still maintained under current package_control_channel and merged into https://github.com/packagecontrol/channel.

That's actually the reason why https://github.com/packagecontrol/channel has its very generic name. The intented target repo for a new package control channel. It was never planned as library-only channel, but as the new home for everything.

The only other alternative was a repo "packages_channel" or something like that under sublimehq, acting as single source of truth, but it wouldn't change anything, technically.

Hence asset based releases are here to stay and must be supported. They are actually not much more complicated than tagged based onces. The GraphQL query is already done. Need to add the asset-template logic to resolve them to assets.

I know you don't want to hear it, but with that strategy in mind thecrawl also needs to mimic PyPiClient for the sake of backward compatibility with ST3-only release of PC4 and to be able to handle current libraries repository, which is also part of package_control_channel/four-point-oh

[michaelblyons]

And here are the subtile agressive attacks again, just because you completely missing the point!

I read his comment as sympathy, not an attack.

[braver]

The status quo is that PC for packages doesn't support assets. To move away from our dependency of the packagecontrol.io and any repositories we don't control (which is what the replace pc.io milestone is about), we don't need support for assets: it's a new feature. And an important step forward eventually. Just not for this milestone.