-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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.
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
Add SBNF #8826
Add SBNF #8826
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automated testing result: ERROR
Repo link: SBNF
Results help
Packages added:
- SBNF
Processing package "SBNF"
- ERROR: '.sublime-package' files have no business being inside a package
- File: .sublime-package
- WARNING: The package does not contain a top-level LICENSE file. A license helps users to contribute to the package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automated testing result: WARNING
Repo link: SBNF
Results help
Packages added:
- SBNF
Processing package "SBNF"
- WARNING: '.no-sublime-package' is defined. Please verify that it is *really* necessary
- WARNING: The package does not contain a top-level LICENSE file. A license helps users to contribute to the package.
Directly pushing binaries to a tag seems rather uncommon. Wouldn't it be more obvious to create a dedicated download artefact and upload it for each release? This way each release could contain a SBNF.sublime-package and maybe binaries for direct use? The package itself works, well, except I wouldn't use It has 2 side effects:
|
A readme, describing the package and maybe a license file should be specified, so packagecontrol.io can display a description of what the package does. URL of a README can be specified explicitly in repository.json or if present is used from the tag's commit. |
Not sure what you mean by this. Are you suggesting SBNF include a python plugin that downloads the binaries? |
What I mean is to let a tag point to a normal commit on master branch and deploy a downloadable asset in related release, instead of pushing compiled binaries to a separate Example:
It would basically mean to extend the github workflow to create a zip file (or sublime-package) with all the package content (binaries, syntax files, ... - which is currently pushed to # - compile binaries
# - pack everything to SBNF.zip or SBNF.sublime-package
- uses: actions/upload-artifact@v3
with:
path: |
*.sublime-package This way it keeps pretty obvious which commit a tag/release belongs to, which might not be too obvious, with current strategy. TBH, I just stumbled over |
Right, how can that be hooked up to package control? |
Well, I totally forgot about wbond/package_control#1484 as "easy to use" solution for Bitbucket/Github/Gitlab deployed packages. A common practice I've seen so far is to manage a Actually Package Control is deployed this way. the package in package.jsonthe include in channel.jsonWell, finally your current approach is probably easier and not that cumbersome with regards to usability. |
I've made a repository and am uploading artifacts as part of gh releases now. Adding a custom repository works and installing the package succeeds. Only issue is that package control isn't extracting the executable flag, so my executables/shell scripts aren't working. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automated testing result: ERROR
Repositories added:
- https://raw.githubusercontent.com/BenjaminSchaaf/sbnf/master/package_control/packages.json
Processing repository "https://raw.githubusercontent.com/BenjaminSchaaf/sbnf/master/package_control/packages.json"
- Found 1 package
Packages added:
- SBNF
Processing package "SBNF"
- ERROR: fetching package HTTP error 302 downloading https://github.com/BenjaminSchaaf/sbnf/releases/download/0.6.4/SBNF.sublime-package.
With regards to executable flag:
It's possible to add that, however would it work for those using a future release of PC, only. |
It appears package reviewer bot doesn't handle redirects. Release assets are redirected to something like:
Despite that limitiation, I can confirm adding the repository.json locally, enables installation of SBNF without issues. |
Have you tried PC3? I recall this (the redirect handling) being a blocking issue for some packages. |
Yes, PC3.4.1, Windows 11, using urllib and wininet downloader. I also didn't find evidents for it not working when I was looking into wbond/package_control#1502. wininet is used on Windows, by default. urllib on Linux/MacOS. Redirects are a default "handler" in urllib, wininet handles it transparently. I haven't checked curl, wget and osscrypto downloaders. packagecontrol.io doesn't download or handle packages and thus - even if it suffers - shouldn't realize it. I agree, however it not being an ideal and confusing circumstance. |
I've submitted patches to both package control 3 and 4 to extract file flags, in testing both were able to install SBNF with the right flags on Linux. |
Now that PC4.0 is out, which restores executable bits, it's safe to merge this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automated testing result: ERROR
Repositories added:
- https://raw.githubusercontent.com/BenjaminSchaaf/sbnf/master/package_control/packages.json
Processing repository "https://raw.githubusercontent.com/BenjaminSchaaf/sbnf/master/package_control/packages.json"
- Found 1 package
Packages added:
- SBNF
Processing package "SBNF"
- ERROR: fetching package HTTP error 302 downloading https://github.com/BenjaminSchaaf/sbnf/releases/download/0.6.4/SBNF.sublime-package.
@deathaxe just to be sure, can we ignore the 302 here? |
Yes, we can. |
My package is SBNF
I'm not 100% sure if the older tags are a problem. The newest tag and all future ones are on a different orphan branch that includes binaries.
There are no packages like it in Package Control.