-
Notifications
You must be signed in to change notification settings - Fork 134
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
Add stratum-cli
project
#1115
Add stratum-cli
project
#1115
Conversation
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
🚨 10 ALERTS: Threshold Boundary Limits exceeded!
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
as much as I think would be a positive change, I feel this scope is starting to move in the direction of optimizations that are not really needed with regards to where the project is right now we agreed on #1066 (and later #1093) because that was a strict requirement for #1120, while I'm not really convinced on the need for a unified binary just yet as I already stated in our dev calls, I feel that deeper changes to the application layer should be left for a more distant future, once we are already done with #845 and we have a more clear outline on the ideal architecture for the application layer that are still under conceptual discussion under #1069 don't get me wrong, I do feel a unified CLI would be ideal for the long term, as I already proposed via #1069 (comment) but for now, I feel our time and efforts would be better spent if we focused on either: @jbesraa can you elaborate on what you see as the immediate benefits of this change? why should we focus on this sooner rather than later? |
Why do you think so? Our project does not have a proper entry point, which is one of the first things usually done in projects.
Adding a
How would #845 affect this change? I do not think its related in anyway. Adding a cli app could be discarded if you think there is a better way to expose our libraries to the end user, but I do not see how #845 can be a factor here. Moreover, the work on #845 is gonna take at least a year if not more, I have a few open PRs that are waiting for review for a bit and they are not moving forward. #845 Only changes the protocols code which I think should be in general the lowest priority for the following reasons:
Both #845 and #1120 are work in progress and have open PRs that should be reviewed so I am not sure why adding CLI should be blocked by those?
|
In general, it would be better to stop thinking about everything as a refactor. Even when adding this 'stratum-cli' there is none refactoring, its merely a code organization putting things in there correct place. |
it's not a matter of blocking, but a matter of how we strategize about where our collective efforts are focused the reason progress on #845 and #1120 have been slow is the fact that we are a small number of contributors, and unless we keep our scope under reasonable and manageable constrains, our efforts will be scattered and progress will be slow everywhere with
the lockfiles issue could be mitigated via CI, as proposed via #1102
removing so we can't break the current we would also need to adapt docs and communicate those changes to adopters who are currently experimenting with the current which brings me back to my original point: this might seem like a good direction at a first glance, but it opens up many cans of worms that will inevitably drain our energy into new unforeseen directions... in an ideal world where all SRI contributors had infinite bandwidth for tackling all those implications, sure, that would be ok... but unfortunately we need to be very strategic about how we focus our efforts my bottom line here is: I'm not strictly opposed to UI enhancements for |
Note: This PR is still a draft and I do not expect it to be merged in less than a month TBH as it depends on the integration test PRs, but I do think its a good point to start the discussion and try and reach a consensus.
Currently this only covers the
translator
andjdclient
. In order to test it locally, you can build the branchcargo build
and then./target/debug/stratum-cli translator start-local
. For a full list of commands, try./target/debug/stratum-cli help
blocked by #1092, #1097 and #1095
.. this should allow us to remove
main.rs
files from all the roles and leave them as pure libraries