-
Notifications
You must be signed in to change notification settings - Fork 525
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
Issue #340 : Remote links for single file: HTTP (fsnip, etc.) and Gist #353
Conversation
|
||
[<Test>] | ||
let ``should read http source file from config without quotes, parsing rules``() = | ||
// The empty "/" should be ommited. After that, parsing amount of "/"-marks: |
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.
Why it should be omitted? Web server can handle those two urls differently.
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.
Usually this is not a problem as usually you know the file name you want to reference. :-) If there is just file reference e.g. "http https://example.com/some.txt" without any file-spec (file names) then it will use the last part of url as system file name (here: some.txt).
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.
I'm complaining not about the name for the file you find out by splitting the url. Although why do we assume .fs
as default file ending being referenced?
My initial complain was about different resource could be delivered for the altered url.
http://example/item != http://example/item/
While you could use GitHub just as another http-site, it still is better to have also separate GitHub:
|
yes that's not what I meant. It's good the way it is |
It would be nice if we could put checksums on the plain http sources like with github. I'm thinking of using packet as a way to manage DB script deployments and having that checksum would help here as well as in simpler scenarios. |
What would happen if the checksum didn't match? |
I'd consider this a versioning mechanism, so if the checksums don't match it would mean we were unable to resolve that version. (I.e. What would happen if the version specified for a nugget package didn't match? It would be an error right?) |
I see where you're coming from... I think that optionally using a checksum as a fallback is a good idea but I'd sooner see something explicit e.g. versioning within the URI e.g. http://myresource/1/foo.fs and http://myresource/2/foo.fs than a checksum. |
Support for any http-source download link.
Gist also suported multiple files so it is separte from any http-source.