wbond
Support download of custom build artifacts
Package Control downloads packages from https://codeload.github.com/<user>/<repo>/zip/<tag> which always downloads the whole exported repository of the given <tag>.
A plugin author might want to run a deploy workflow to create custom build artifacts, which may contain external libraries which are not part of the repository itself. Those build artifacts are available for download via https://github.com/<user>/<repo>/releases/download/<tag>/<artifact>. The <artifact> is file name such as Emmet.zip.
At the moment an url key needs to be specified in the repository.json to download such custom files.
How about adding a download key, which if present is used to build the download url?
Example:
{
"schema_version": "3.0.0",
"packages": [
{
"name": "Alignment",
"details": "https://github.com/wbond/sublime_alignment",
"download": "https://github.com/${user}/${repo}/releases/download/${tag}/Emmet.zip"
"releases": [
{
"sublime_text": "*",
"tags": true
}
]
},
]
}
Maybe we can go a bit further with this? the github api has a wealth of info.
{
"schema_version": "4.0.0",
"packages": [
{
"name": "Package",
"github": "user/sublime-package"
}
]
}
Only problem seems to be the missing "subime_text" key. But, if we all agree upon the idea that tags can be of the form BBBB-x.y.z, where BBBB is the minimum supported ST build version, then this should all be possible to work out what the latest release is for a given sublime version.
Github is only one of several supported hosting platforms. Hence a key like github may be a bit too specific. A key would be needed for each hoster (gitlab, bitbucket, ...) and further would need to be added for each new platform then.
Maybe we can go a bit further with this? the github api has a wealth of info.
Our current approach is to use URLs, and then write code that can consume those URLs. I don't see why we'd need to add a key github when we can already consume GitHub URLs. The way that we could consume more of the GitHub API info is to add code to the GitHubRepositoryProvider.
What would be a logical enhancement would be to change the releases key of the PC schema to add a new sub-key... releases 😄 next to tags and branches.
If GitLab supports such a feature, someone could implement it in the GitLab provider.
