Closed nightroman closed 6 years ago
This doesn't really fit with the term url
so my initial thought would be to add a path
field where either url
or path
must be present.
I'm not quite convinced this is really a necessary feature however.
Thoughts @lukesampson?
A special field would be even better.
I'm not quite convinced this is really a necessary feature however.
It is not necessary. But scoop is not necessary, too. Still they make things easier.
@nightroman do you mean file
URIs? Relative paths by themselves are rather vague as they need to be relative to something. Somehow, Scoop needs to determine the fully qualified path of the item to install. But I can definitely see the use case for supporting file URIs, which would all you to reference files on a network share that is not available via HTTP/HTTPS. Was that more where you were going with this request?
@damnhandy
Relative paths by themselves are rather vague as they need to be relative to something.
I mean paths relative to manifest files.
That should work just fine today. If you're creating or updating manifest files, you can do the following:
scoop install .\bucket\git.json
That works just fine. If that what you're looking to do?
@damnhandy, no. I am talking about the field "url" in JSON manifests. Currently it supports web URLs (obviously) and full file system path (not obviously but this is the fact). But it does not support relative file system paths, relative to the manifest location, indeed.
I do not think it is resolved. If I use a relative path to an archive then I get:
> scoop install z1.json
installing z1 (0.0.1)
downloading ./z1.7z...Invalid URI: The format of the URI could not be determined.
P.S. It is fine if the issue is closed as not needed, won't fix, etc. But not as resolved or fixed.
Relative to what? The manifest?
Relative to what? The manifest?
Yes. The use case is a local zip package and a satellite manifest in the same directory. The manifest provides installation details. scoop already does the job with full local paths. But this is not practical.
For myself, I solved the problem. I use an extra command which reads a manifest with relative paths, resolves them to full (with respect to the manifest location) and makes a temporary json. Then this new json is passed in scoop. Still, it would be nice if scoop understands relative paths (e.g. paths starting with dots) and resolves them to full itself.
Closed as solved locally and not interesting as a public feature.
Would it be possible to allow manifests with relative paths to sources, i.e. local zip files? Right now only full paths are supported.
Use case: I have some local tool packages with known locations and all I want is to install and uninstall them easily with scoop. It would be nice if I can keep a scoop manifest together with a tool archive, hence a relative path is needed.