-
Notifications
You must be signed in to change notification settings - Fork 406
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
Include github URLs in list.json #19
base: gh-pages
Are you sure you want to change the base?
Conversation
pars.urls = [ | ||
'bzzr://' + swarmhash(fileContent).toString('hex'), | ||
'https://ethereum.github.io/solc-bin/bin/' + pars.path, | ||
'http://ethereum.github.io/solc-bin/bin' + pars.path |
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.
Actually since we have solc-bin.ethereum.org
as a redirect there, should we use that?
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 do we need absolute links here? This file is just a summary of the other files in the same location.
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.
It would work if we consider the current approach with github pages, however I was thinking about having the "manifest" (list.json
) available on swarm or ipfs and as such it would need absolute URLs.
We could include a relative path as an option in the URLs though.
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.
Actually if you use a swarm manifest, that would be an argument to use relative paths (which are then valid both inside swarm and inside github pages).
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.
Actually if you use a swarm manifest, that would be an argument to use relative paths (which are then valid both inside swarm and inside github pages).
I am not entirely sure how that would work with Swarm manifests and whether we want to keep this /bin
directory at all.
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.
Oh btw it is a URL and not a path. Not sure how to represent relative paths on URLs.
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.
We already have the path
member, so actually no need to put them here at all.
We could add ipfs urls, though...
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 think we actually want to add the official https://binaries.soliditylang.org/...
URL.
Reason: all the URLs we have in this array are pointing to a specific file and are not paths within a manifest/collection. If we publish list.json
+ the paths as a collection as well, for that use case the consumer can try the path, otherwise if list.json
is just independently published on IPFS or swarm they can still opt to acquire the files via various means.
ping @chriseth |
@axic Maybe, instead of adding new URL variants to the list in every dict we should rather add a separate, top-level key with official sources? The number of sources will probably keep getting bigger. We already want to add IPFS so that'll be 4 items per file. The dicts already contain enough information to construct URLs if you know the source. Also, I think that having a list of official sources (either in the file, or maybe just in README) would have helped us with the transition to S3. |
I would prefer it if this is really an index of the current list - and thus does not depend on or contain any information about where it is located. |
How about including a separate, static file in the root of the repository, with a list of possible source URLs? |
"bzzr://8f3c028825a1b72645f46920b67dca9432a87fc37a8940a2b2ce1dd6ddc2e29b" | ||
"bzzr://8f3c028825a1b72645f46920b67dca9432a87fc37a8940a2b2ce1dd6ddc2e29b", | ||
"https://ethereum.github.io/solc-bin/bin/soljson-v0.1.1+commit.6ff4cd6.js", | ||
"http://ethereum.github.io/solc-bin/binsoljson-v0.1.1+commit.6ff4cd6.js" |
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.
Shouldn't this be
"http://ethereum.github.io/solc-bin/binsoljson-v0.1.1+commit.6ff4cd6.js" | |
"http://ethereum.github.io/solc-bin/bin/soljson-v0.1.1+commit.6ff4cd6.js" |
?
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
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.
good
@axic @cameel should we close this? And instead work in the other suggested approaches here: #19 (comment) and here: ethereum/solidity#2238 (comment) |
After this change it is possible to rely only on
list.json
in a client. The client can look forhttp://
orhttps://
depending on what they run on.