8000 Support download of custom build artifacts · Issue #1484 · wbond/package_control · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Support download of custom build artifacts #1484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
deathaxe opened this issue Aug 3, 2020 · 4 comments
Closed

Support download of custom build artifacts #1484

deathaxe opened this issue Aug 3, 2020 · 4 comments
Labels
enhancement
Milestone
Package Control 4.0

Comments

@deathaxe
Copy link
Collaborator
deathaxe commented Aug 3, 2020

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
				}
			]
		},
	]
}
@rwols
Copy link
Contributor
rwols commented Oct 29, 2020

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.

@deathaxe
Copy link
Collaborator Author

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.

@wbond
Copy link
Owner
wbond commented Oct 30, 2020

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.

@deathaxe deathaxe mentioned this issue Oct 8, 2023
Merged
11 tasks
@deathaxe deathaxe added this to the Package Control 4.0 milestone Nov 26, 2023
@deathaxe
Copy link
Collaborator Author

That's supported as of PC4.0.0-beta9 with support for PyPI as of beta10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
Package Control 4.0
Development

No branches or pull requests
3 participants
@wbond @rwols @deathaxe
0