Include github URLs in list.json #19
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.
Actually since we have solc-bin.ethereum.org as a redirect there, should we use that?
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
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.
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" |
?
|
@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.jsonin a client. The client can look forhttp://orhttps://depending on what they run on.