Webui problems

[jbenet]

@mappum these are webui problems:

• old hashes should remain allowed for users who have links
• there should be a "how to publish a new webui" section in a readme inside corehttp/.
• there should be a Makefile in ipfs-webui that npm installs and delegates to gulp. typing make is the only think we can expect developers to know.
• there should be a make bundle makefile target in ipfs-webui that compiles, and prints out instructions to the user on how to publish the webui. ipfs add -r
• there should be a make publish makefile target in ipfs-webui that compiles the bundle, + publishes the hashes for you, assuming you have an ipfs daemon running.
• before publishing any webui make sure it's served on the gateway. the latest hash is simply not available, and i dont know how to build it. the current build/ does not match the hash you put in.

Please be more careful with these things. they break on users. and i can't even fix it right now. 😢

[jbenet]

• no hardcoding of hostnames or ports. webui should work with whatever host its on. (so should ipfs-api)

[mappum]

@jbenet Aren't make bundle and make publish the same thing? Do you mean publishing via IPNS?

[jbenet]

i'm thinking something like:

bundle: build/bundle.js build/index.html ...

build/bundle.js: deps
    node_modules/.bin/gulp compile

publish: bundle
    hash=`ipfs add -q -r build/ | tail -n1` && echo "published at $hash"

[mappum]

I'm not sure where the bundle indeterminism is coming from, I thought that was previously solved. It might be easier to just be able to push a hash to the gateways, then they can get and pin the refs, rather than expecting them to build the same bundle.

[jbenet]

and you're for sure at deabd49 ? do you get different bundles with different runs?

[mappum]

and you're for sure at deabd49 ?

Yes.

do you get different bundles with different runs?

Re-cloning the repo and npm installing changed the bundle, but repeating that always gets the same output. The hash I'm getting is QmbjEC2EeMNcLonYyRgbUjoxeeN1YSRN2pVUw9ze9JivFn.

[jbenet]

npm installing changed the bundle

yeah this seems flakey. what if we fix to exact versions of stuff in the package.json?

[mappum]

yeah this seems flakey. what if we fix to exact versions of stuff in the package.json?

Alright, that might be where the changes are coming from.

[mappum]

Actually I'm not sure that will solve it, since 2nd level dependencies are likely not fixed to exact versions, and will suffer the same problem.

[jbenet]

then maybe we should commit + keep all the built versions:

versions/QmbjEC2EeMNcLonYyRgbUjoxeeN1YSRN2pVUw9ze9JivFn/...
versions/...

so that we can make sure we can republish any of them should we need to.

[mappum]

Alright, I added the latest bundle to the repo. Now the gateways should just ipfs add -r versions whenever the repo changes, and all bundle versions will be available.

[jbenet]

:m1:

mappum: do you have the old ones?

also, npm install never terminates for me...

[mappum]

do you have the old ones?

Nope. We can just update the hash in go-ipfs and start supporting all versions after this one.

also, npm install never terminates for me...

You might need to update npm? Mine is on v2.5.0.

[jbenet]

We can just update the hash in go-ipfs and start supporting all versions after this one.

@mappum sgtm. I have one still. just pushed it to protocol/ipfs-webui (i'd push it to yours but git tells me i cant)

[jbenet]

this should be moved to protocol/ipfs-webui