-
Notifications
You must be signed in to change notification settings - Fork 57
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
feat: rln-keystore-generator is now a subcommand #2189
Conversation
This PR may contain changes to configuration options of one of the apps. If you are introducing a breaking change (i.e. the set of options in latest release would no longer be applicable) make sure the original option is preserved with a deprecation note for 2 following releases before it is actually removed. Please also make sure the label |
You can find the image built from this PR at
Built from 33d3bfb |
Thanks! Some tests are failing but from a functionality point of view this is exactly what we need. For context, this is to ship the
Which is the same image as for running nwaku. |
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 feature!
Thanks @alrevuelta @rymnc ! |
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 approve because I don't want to be a blocker on that, but I'd rather have separate binaries with clear separate responsibilities, if that makes sense and is feasible of course :)
imho, that we need another binary, docker image, etc. Having these kind of tools inside nwaku makes it very easy to use, and requires less cognitive load (less amount of binaries/images). As long as they are light (doesn't make the docker image more heavy) and related to nwaku, I think its a good idea to have them. Even this could be part of it. |
Thanks for the comment! ❤️ I vote for having all the "rln" stuff in separate binaries, as we had before this PR. I'm kind of having that as a temporary solution but to me, the best is having a clear separate Docker file, binary, etc. wdyt: @NagyZoltanPeter @SionoiS @gabrielmer @rymnc @jm-clius |
I somehow agree with @Ivansete-status here. the tools can be their own docker image with just one entry point, where nwaku remains on its own. I don't mind either approach, but leaning towards Ivan's suggestion |
@rymnc @Ivansete-status I actually got the idea from projects like |
Same here :) I'm also keen on the idea of having separate images for independent tools/services, and creating an unique entry point that can combine them all in an user-friendly way. I think it serves the purpose of the user having everything in one place while being more organized and maintainable |
Thanks for sharing that! |
How many of those "useful" command do we have? At some point we should separate them but I feel it would be premature in this case. |
Personally I more fan of such approach as @alrevuelta. We all working with such tools (git, cmake, even docker just to also name some). But! I feel for nwaku we started to confuse our wished users. In case we have nwaku/go-waku/... and they not matching in some key feature set, one can think we are much distracted and not coordinated team. |
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.
Apart from the different viewpoint on overload nwaku with somee tooling it looks fine!
Description
As per request from @alrevuelta, rln-keystore-generator is now a subcommand in nwaku.
Changes
Pending
How to test
make -j16 wakunode2