WIP: Fix Aragon breaking changes; update dependencies #182
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "chore/update_dependencies"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Dance the update dance with me.
arapp.json exception
The only documented options for the
apm
config property are now related to IPFS. So I removed what seem to be outdated values on our end, and the devchain works again.Other Aragon CLI changes
package.json
. I removed it everywhere.aragon contracts
anymore. Neithercompile
nortest
. It looks to me liketruffle test
should work (it runs stuff and complains about things), but there are test failures now. Probably due to other oudated API calls in the tests (e.g.dao.acl()
).App package questions
@haythem96, @bumi: To be honest, the separate
package.json
files look like a mess to me, and I don't understand how these are used exactly, because the Travis config is not actually runningnpm install-all
before running tests. Travis also doesn't seem to compile contracts before testing, so unless you commit and push compiled changes, I don't see how it could catch test failures in PRs.These question should be solved either in this PR or with a new one focused on fixing the test setup. I won't touch the code in this branch from here on, so please feel free to work on this branch and push fixed tests.
closes #179
Thanks for this PR! I could get the contracts running using this update. (pushed a minor update here)
I am not sure about travis and the tests currently fail on my machine:
arapp.environments[environment].apm
has to be an object now, so the first condition here is not going to work anymore.what does not work anymore?
that
apm
entry in the arapp.json (removed in this PR) was added/used by us - and not aragon related.We had used that entry when
open.aragonpm.eth
was not available on all networks (and we had to usearagonpm.eth
locally.now we can default to
open.aragonpm.eth
I've updated some tests, now it fails with:
Please read my original PR description and follow the link. The entire reason for opening this PR was an exception about this particular
arapp.json
property having to be an object now.That would explain why it's not documented. They introduced this property themselves in the meantime, but with different keys.
this is a WIP PR, isn't it?
I was trying to debug that issue and get this update running here.
that configuration conflict is not solved, yet and the tests do not run, yet.
re:
apm
entry in the arapp.json file I tend to not have the apm registry configurable anymore. We now can rely onopen.aragonpm.eth
(locally and for all Ethereum netwroks we want to deploy to)Not sure how your comment relates to what I'm trying to explain. The config issue was solved by me removing the custom
apm
property, because Aragon now requires it to be their own documented object as a value (the one with the IPFS configs). The test failures are a different topic.I explained these things in the original PR description, with separate headlines and paragraphs for the various topics this PR touches.
To summarize my one comment on this one line of code again:
arapp.environments[environment].apm
cannot be a string with an APM address anymore, as per their documentation. And it fails with an exception when trying to execute any aragon-cli command that encounters this config property as a string.I hadn't seen that it was used in other places, so what fixed the aragon commands for me was just to remove the keys from
arapp.json
.which broke the setup/deployment of kredits and that's what I am trying to fix here...
It seems you did not change any code there?!
And I know that
apm
is now a aragon related property and can not be used and I also read your comments...maybe I should better make a PR to your PR then we don't need to somewhat discuss WIPs and avoid missunderstandings.
ToDo:
see: https://github.com/aragon/deployments/tree/master/environments/rinkeby
I cannot know what you know, because I don't have a telepathic link to you. Until this last comment it seemed like you hadn't understood my original comment. And my original comment was merely a pointer to that config option being outdated.
If you already understand something that someone points out, then why not just say "Yeah, I know, I'm working on that"? Or even nothing at all, if it's of no consequence to my involvement.
to me it seems you did not understand what that
apm
was used for and why your change broke our deploy script.but I also don't know what you know, because I also don't have a telepathic link to you.
anyhow this discussion now seems to be unrelated to this PR and also on already outdated code, so I am resolving this now.
merging this as discussed. The other fixes should be done in separate PRs.
keeping the WIP to indicate some work is missing
btw. @haythem96 can you help with the contract upgrades?