Skip to content
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

Merged
merged 3 commits into from
Nov 11, 2014

Conversation

Thorium
Copy link
Member

@Thorium Thorium commented Nov 10, 2014

Support for any http-source download link.
Gist also suported multiple files so it is separte from any http-source.

@Thorium Thorium mentioned this pull request Nov 10, 2014
@forki
Copy link
Member

forki commented Nov 11, 2014

enough

This looks really really good. I'm really excited about this.
Especially the fact that "github" sources are now a special case of http sources is amazing.

I will test locally, merge and release a new alpha. Then we will work from there if needed.

Good work!

@forki forki merged commit 56a7e10 into fsprojects:master Nov 11, 2014

[<Test>]
let ``should read http source file from config without quotes, parsing rules``() =
// The empty "/" should be ommited. After that, parsing amount of "/"-marks:
Copy link
Member

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.

Copy link
Member Author

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).

Copy link
Member

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/

@Thorium
Copy link
Member Author

Thorium commented Nov 11, 2014

While you could use GitHub just as another http-site, it still is better to have also separate GitHub:

  • When we know the structure of an url, we can handle more data
  • From GitHub you can reference the whole project, multiple files, which is not possible from just an url.
  • Compatibility...

@forki
Copy link
Member

forki commented Nov 11, 2014

yes that's not what I meant. It's good the way it is

@DamianReeves
Copy link

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.

@isaacabraham
Copy link
Contributor

What would happen if the checksum didn't match?

@DamianReeves
Copy link

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?)

@isaacabraham
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants