Closed dternyak closed 6 years ago
Hm - the gradle stuff is not used for WallETH here - it is used for the CI to check/assemble the content. Already added this to the MEW/ethereum-lists but there I could not automate the CI and had to run the scripts manually - this is now possible here. I do not see a way to move this to another layer without loosing this function. Would love to keep this as it removes manual work. Can you elaborate why this prevents you from using it in your project?
I think the primary issue here is that it's hard to integrate this repository if the gradle build process is required to get at the lists. I think what would make this (And most of the ethereum-lists repos) most useful is if there were a branch that only contained the built files and had tagged releases, so that others could use them more easily.
Alternatively, using these repos to make NPM modules that do the compilation upon install could be dope as well, especially since a large portion of Ethereum projects involving tokens etc are JS-based.
The build-scripts are automatically executed by the build-server and the files end up on IPFS. I do not really get the idea with the branch - can you elaborate on this? Not sure about NPM - I do not touch JS - only doing statically typed languages ;-) But I am open to ideas .. I can do versioning for sure - need that anyway for my integration in WallETH
Oh, had no idea about IPFS. That would be great to put in the readme, so people know how to digest this data.
As for a separate branch, it'd be kind of like Github's pages via the gh-pages
branch. Your compiled assets get put on a separate branch meant for consumption, but your source code still lives on master.
@wbobeirne thanks for the suggestion - I imrpoved the README - hope this is more clear now. Not sure about the extra branch - but I could imagine uploading this as release files on github - would this work for you?
Thanks for the readme adjustment! I wouldn't worry about the extra branch for our use cases, I think if we get around to integrating ethereum-lists
's repos, we'll very likely make an NPM module that wraps them. Though you may find more adoption in general if it's easy to integrate into other projects without having to run the gradle code, ideally a more programatic way of getting to the latest IPFS release.
Great! Personally I find the usage of NPM a bit frightening - as far as I understand there is nothing like gradle witness for NPM - this is a catastrophy waiting to happen .. I could also publish the lists for the latest commit via IPNS I think - so getting the latest lists is very easy - would this work for you?
Yarn does, for those who are worried. Also I would most definitely add typescript definitions, for those who like static typing. JS ain't quite the wild west it used to be 😉
This seems like a great use-case for IPNS, though I'll admit I'm a little out of my depth with the implications and limitations of IPFS and IPNS, so I can't definitively say if this does exactly what we need. Might need someone more well versed to confirm.
great to hear about typescipt - closing this here as it is not really actionable for me and there should be other solutions to the problem - if not please let me know!
@ligi Thanks for the heads up about auto-upload to IPFS on commit. Thats incredibly useful.
Unfortunately, following your instructions didn't bring me to a a page where I could ethereum tokens, only kovan, etc (see screenshot).
Do you mind pointing me in the right direction?
thanks - unfortunately the hdd of the server went full and the last commit is not build fully. Look again and you will find the files needed - then looks like this:
in the folder file/output/
Thanks for starting up this organization! I think this is a great step forward for ensuring that a community maintained token list is kept up-to-date and available!
One issue that the team at MyCrypto is having with this (and the older)
ethereum-lists
is that the gradle specific configuration doesn't allow us to integrate this token list as a git submodule.What do you think of moving the
tokens
directory down one level, and removing the existing gradle packaging / handling that in another layer for WALLETH?It would certainly be really helpful for us to only have one source of truth for tokens, which hopefully this repo can become.
Let me know if there's anything I can do to help! Happy to PR the change myself, but wanted to start the discussion so that you weren't taken by surprise by such a PR.