Closed kidonng closed 1 year ago
Yeah, I'm interested myself, but have no time to do it.
basics
I've tried to get scoop running on pwsh on docker container, but did not have success yet. I'm happy to support if somebody sends a pr for the basic package manager here and here
Any new datasource needed or is it just GitHub repos?
It depends on the application which needs an update. Scoop is a application installer / updater like chocolatey / brew
When writing a new manager I think it's easiest to implement datasource -> versioning -> manager, so that's why the first step for me is defining which datasources we need and if any need adding.
There is no general datasource for scoop bucket config files. see here for a sample
If we need to support every file, we would need houndreds of datasources. I think for most files we can simply reuse existing datasource, eg here github-releases
can be used.
I would also use semver
or loose
as default versioning, as every application can have a different versioning.
So my suggestions here is to get scoop running on ubuntu pwsh and add a scoop manager and see how far we can get.
{
"version": "1.0.8.0",
"homepage": "https://github.com/philr/bzip2-windows",
"description": "Freely available, patent free, high-quality data compressor",
"license": "MIT",
"architecture": {
"32bit": {
"url": "https://github.com/philr/bzip2-windows/releases/download/v1.0.8.0/bzip2-1.0.8.0-win-x86.zip",
"hash": "c1d31f9c5f01a5a4ac91c703a07c108a433803c50e65e22aea0815eecd9fb94a"
},
"64bit": {
"url": "https://github.com/philr/bzip2-windows/releases/download/v1.0.8.0/bzip2-1.0.8.0-win-x64.zip",
"hash": "f931dc91fb02dc8aa8739a3c0a0c8ec78789fe87cb6611a4c78ca2937d197708"
}
},
"bin": [
"bunzip2.exe",
"bzcat.exe",
"bzip2.exe",
"bzip2recover.exe"
],
"pre_install": "cp \"$dir\\bzip2.exe\" \"$dir\\bunzip2.exe\"; cp \"$dir\\bzip2.exe\" \"$dir\\bzcat.exe\"",
"checkver": {
"github": "https://github.com/philr/bzip2-windows"
},
"autoupdate": {
"architecture": {
"32bit": {
"url": "https://github.com/philr/bzip2-windows/releases/download/v$version/bzip2-$version-win-x86.zip"
},
"64bit": {
"url": "https://github.com/philr/bzip2-windows/releases/download/v$version/bzip2-$version-win-x64.zip"
}
}
}
}
{
"version": "1.0.9_5",
"description": "Lossless compression algorithm",
"homepage": "https://brotli.org/",
"license": "MIT",
"architecture": {
"64bit": {
"url": "https://curl.haxx.se/windows/dl-7.73.0_5/brotli-1.0.9_5-win64-mingw.tar.xz",
"hash": "62bb48f6057e29abbb9a530aded28cc3dbb6b0d7ef878aa8e434f76f47020559",
"extract_dir": "brotli-1.0.9-win64-mingw"
},
"32bit": {
"url": "https://curl.haxx.se/windows/dl-7.73.0_5/brotli-1.0.9_5-win32-mingw.tar.xz",
"hash": "5b40c1d8bb83e5a3ce3a748d6fb4eb220edcc44c17110289b30d5c0253b5f2eb",
"extract_dir": "brotli-1.0.9-win32-mingw"
}
},
"bin": [
"bin\\brotli.exe",
"bin\\unbrotli.exe"
],
"pre_install": "Copy-Item \"$dir\\bin\\brotli.exe\" \"$dir\\bin\\unbrotli.exe\"",
"checkver": {
"url": "https://curl.haxx.se/windows/",
"regex": "dl-(?<curl>[\\d._]+)/brotli-(?<version>[\\d._]+)-win64-mingw"
},
"autoupdate": {
"architecture": {
"64bit": {
"url": "https://curl.haxx.se/windows/dl-$matchCurl/brotli-$version-win64-mingw.tar.xz",
"extract_dir": "brotli-$matchHead-win64-mingw"
},
"32bit": {
"url": "https://curl.haxx.se/windows/dl-$matchCurl/brotli-$version-win32-mingw.tar.xz",
"extract_dir": "brotli-$matchHead-win32-mingw"
}
},
"hash": {
"url": "$baseurl/hashes.txt",
"find": "SHA256\\($basename\\)=\\s+([a-fA-F\\d]{64})"
}
}
}
If i read this correctly, we need the checkver
property to get the datasource. If we try to compute the sha256 ourself from autoupdate
, we can build a plain ts/js manager without require running scoop to update the hashes.
ok, brotli shows a sample for having a simple regex url datasource for renovate 😉
We need a way of knowing what the possible newer versions are. It might need per-package manual configuration and perhaps the generic datasource capability first #6223
sure, but i'm also pretty sure we can catch a lot of those pacakges with our existing datasources 🙃
What about the hash updates? Should we handle them ourself or trying to get scoop running on pwsh on linux?
Either could work, so maybe we try our own hash approach if there's already difficulty running that binary.
yes, scoop will run on pwsh, but the code is very windows specific, so can be difficult to get running on linux. So i would suggest to use a ts/js only approach
Hi there,
You're requesting support for a new package manager. We need to know some basic information about this package manager first. Please copy/paste the new package manager questionnaire, and fill it out in full.
Once the questionnaire is filled out we will evaluate if adding support for this manager is something we want to do.
Good luck,
The Renovate team
Hi there,
Get your issue fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.
Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.
To get started, please read our guide on creating a minimal reproduction.
We may close the issue if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.
Good luck,
The Renovate team
What would you like Renovate to be able to do?
As there was #2738, I wonder if Renovate could also provide auto-updates for custom Scoop buckets since it shares a lot of common with Homebrew.
And there is another thing I want to mention. Scoop's official buckets are using automated updates that aren't very stable and Scoop's community doesn't seem to build a solution that is as competent as Homebrew's. If Renovate could support Scoop buckets updating, it may be used for official buckets as well, which will benefit lots of people.
Did you already have any implementation ideas?
Not currently but I'd like to help.