Manifests with Relative URL Paths (See #444)

[MarkMichaelis]

I'd like to revisit the issue of support for Url paths relative to the manifest (json) path (see #444). i.e. If I install a local manifest with scoop install .\bucket\myapp.json and the manifest has a Url of "url": "https://raw.githubusercontent.com/<Organization>/ScoopBucket/master/bucket/file.bin", then file will be downloaded from the remote repository rather than a location relative to myapp.json.

What I would like is to be able to do is something like this: "url": "$relative_url/myapp.bin" so that when I install the manifest, whether using the remote repo or a local file path, the download will be relative to the manifest location.

This would make a significant difference when testing because I could work entirely locally without having to push files to the remote repo to test.

Thoughts?

[HUMORCE]

you can start a local server

e.g.:

scoop install caddy

create Caddyfile for local server:

localhost:2019
root .\bucket\local
file_server

run caddy server with Caddyfile:

caddy run

example manifest:

"version": "1.0.0"
"url": "http://localhost:2019/example/example-1.0.0.zip"
...

[MarkMichaelis]

Thanks for pointing this out. I don't see how this addresses the problem, however. Now when I push the code to the remote repo, I still have to update the URL. In fact, it emphasizes the point. I want the URL to work regardless of whether the bucket/repo is local or remote. I am looking for the URL to always work relative to the manifest location.

[HUMORCE]

did you put the manifest and the binaries in the same repo?

[MarkMichaelis]

Yes... exactly. For example, in some cases the "binaries" are scripts and I am trying to install or even just run the scripts.

[HUMORCE]

I don't recomment put them in the same repo, but some thoughts:

specify url to small file, then copy app's files by install script:

{
    "version": "1.0",
    "url": "http://example.org",
    "installer": {
        "script": [
            "Copy-Item $bucketsdir\\your_bucket\\scripts\\app.ps1 $dir",
            "Remove-Item example.org",
        ]
    },
    "bin": "app.ps1"
}

defects

1. internet connection is still required.
2. can't ensure that $bucketsdir\your_bucket is correct.

tips

1. create a manifest that never duplicate with other bucket.
2. absolute path of the manifest: scoop info unique-manifest | findstr 'bucket\\unique-manifest.json'.
3. intercept it to get bucket path or name.
4. use it in the installation script

install scripts: https://github.com/lukesampson/scoop/wiki/Pre--and-Post-install-scripts

[MarkMichaelis]

Thanks for the help @HUMORCE. I appreciate your taking the time.

Question:

1. Why do you not, "recommend put them in the same repo." This seems to work very well. If I have a complex install script, it is relatively painful to write it in json rather than in a ps1 file that I put alongside the manuscript.
2. While I think I can see how your approach would work, it seems that the relative path suggestion would make it significantly simpler and, most importantly, less error prone.

Thanks, Mark

[HUMORCE]

1. if put the binaries in the bucket, all binaries will be downloaded when the bucket is added to scoop, this does not include scripts. I will only put the install/setup scripts in the bucket. comparison: 1.CLI util: sudo.json 2.install/setup scripts of extras bucket

2. you're right.

[MarkMichaelis]

@HUMORCE - thanks again for the pointers.

1. While I think I understand your approach, I still suspect that it puts more complexity than I was hoping for. Here are a couple of examples where I find testing (without pushing to Github) difficult:

• GitConfigBeyondCompare.json/GitConfigBeyondCompare.ps1
• McAfeeUninstall.json/McAfeeUninstall.ps1

There are probably numerous issues with both of these scripts. However, the idea of coding either using the script element in a manifest file is problematic. (P.S. I assume my examples are not interesting to others which is why they are not suggested for a public bucket) 2. That's rare... could you blog that, please. I could give you a link to my profile. :)

In summary, I think the relative path would provide a significant simplification by enabling local testing without pushing to the remote repo.

[HUMORCE]

I tried to add this feature to scoop, but that would lead to more trouble.

and I think the reason scoop does not support this feature is: the manifest can copy/move/publish to anywhere, unable to ensure if there is a required file in the relative path.

e.g. the file GitConfigBeyondCompare.ps1 are stored in your github repo(https://github.com/MarkMichaelis/ScoopBucket/raw/master/bucket/), but these paths may not store it:

• [~\]GitConfigBeyondCompare.json
• [D:\]GitConfigBeyondCompare.json
• [https://github.com/humorce/repo/bucket/]GitConfigBeyondCompare.json
• [https://gist.github.com/HUMORCE/???/raw/???/]GitConfigBeyondCompare.json
• [https://example.org/]GitConfigBeyondCompare.json

the format of these URI also varies (protocol/separator).

in your case, all users of the manifest need to add your bucket to the scoop(or their need to setup the scoop with yours settings), because the scoop does not require the {source_url} to be specified in the manifest.