-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feature: add gooey CLI #4805
base: develop
Are you sure you want to change the base?
feature: add gooey CLI #4805
Conversation
I was looking at this for formatting the diff but this is ok for the moment: https://github.com/grigoriy-orlov/git-stats/blob/master/src/main/java/ru/ares4322/gitstats/GitStatsImpl.java |
@@ -30,14 +30,15 @@ class InitCommand extends BaseCommandType implements Runnable { | |||
|
|||
void run() { | |||
println Ansi.AUTO.string("@|bold,green,underline Time to initialize $distro !|@") | |||
def targetDistroURL = "https://raw.githubusercontent.com/$githubOrg/Index/master/distros/$distro/gradle.properties" | |||
String origin = gitOptions.resolveOrigin() |
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.
How does this resolve? We'd run this command in the MovingBlocks/Terasology
repository, but the index repo is located in a different org, Terasology/Index
...
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.
because it's resolving to Terasology/Index
?
gradle/gooeycli/src/main/groovy/org/terasology/cli/GooeyCLI.groovy
Outdated
Show resolved
Hide resolved
If you've decided to stick with Groovy, you may be interested to know that gradle 7 ships with Groovy 3.0. (Related: #4653) |
that sounds really nice |
We should restore |
@DarkWeird were those commands ever properly implemented? |
Don't sure. |
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.
So this is definitely some solid work and I very much appreciate it, and am glad to have at least found enough time to go through the PR just about line by line. Nicely done 👍
This feels like it does really well in areas where the work scratches an important itch, and we have several important itches. But it does also lose some things as a consequence and is somewhat incomplete. Additionally while my first stab was a definite draft effort that lacked stuff and included quirks, I think this one has some different quirks, particularly around some terminology. It also really lacks better docs, be it in the javadoc, command descriptions, usage text, and PR description - even having made it through the whole thing I still don't really understand "snapshots", and that's after having seen it get discussed on chat some and thusly having some more clues. It seems like an awesome feature we badly need, it just really needs some more polish and arranging things in a more user friendly fashion :-)
In that sense this reminds me of my own first effort, as both are incomplete. And I even have a second incomplete effort that was a day job fork where I fixed some of the same issues this PR fixes, yet then I lack some things this covers and fixes other things this one doesn't. Ideally I'd find the time to try splicing my work improvements into this and wind up with a complete work we can then add a few more cool useful things to (like DW's tinkering).
One of the main things in my day job setup is that the workspace has an actual config file, which together with state helps figure out a bunch of things. It seems this mostly is a mix of hard coding and the constants class. Goal was to be able to ship something with workspace config ready out of the box, which in a work context might mean forks of a template that different teams customize. That might still fit in here with distros and temporary "snapshot" thing used to share workspace setup ("junctions" ?)
I don't know what sort of timeline I might be looking at, even reviewing this took all weekend and an innumerous amount of picking it up and putting it away again as I have to go pick up and put away tiny humans in RL. But I'm excited about it again at least so - maybe?
Thank you for the work @pollend (and @DarkWeird!) :-) To be continued, hopefully..
gradle/gooeycli/src/main/groovy/org/terasology/cli/GooeyCLI.groovy
Outdated
Show resolved
Hide resolved
gradle/gooeycli/src/main/groovy/org/terasology/cli/GooeyCLI.groovy
Outdated
Show resolved
Hide resolved
gradle/gooeycli/src/main/groovy/org/terasology/cli/commands/module/ExecuteCommand.groovy
Outdated
Show resolved
Hide resolved
gradle/gooeycli/src/main/groovy/org/terasology/cli/commands/module/ExecuteCommand.groovy
Outdated
Show resolved
Hide resolved
gradle/gooeycli/src/main/groovy/org/terasology/cli/commands/module/GetCommand.groovy
Outdated
Show resolved
Hide resolved
} | ||
Snapshot snapshot = new Snapshot(file) | ||
snapshot.file = new File(Snapshot.SnapshotDirectory,"${snapshot.captured.epochSecond}.snapshot") | ||
snapshot.save() |
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.
Snapshot save on the load command? 🤔
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.
Load into local snapshot repo(just dir) from 'external' locations
|
||
@Override | ||
void run() { | ||
Desktop desktop = Desktop.getDesktop(); |
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.
Huh? Desktop
?
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.
Yeah.
Opens snapshot in your headed environment like double click at this file.
Don't works at headless :D
import picocli.CommandLine.Parameters | ||
|
||
@Command(name = "restore", description = "Restore workspace from snapshot") | ||
class RestoreCommand implements Runnable { |
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.
What is the difference between "load" and "restore" ? The load command even has "restore" in its text
...ooeycli/src/main/groovy/org/terasology/cli/commands/workspace/snapshot/RestoreCommand.groovy
Outdated
Show resolved
Hide resolved
|
||
public static final File ModuleCacheFile | ||
|
||
public static final String ModuleIndexUrl = 'http://meta.terasology.org/modules/list/latest' |
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.
Just as a reminder related to a brief discussion on Slack: while the Meta server still works I'm not sure its metadata is being reliably refreshed. The Index repo is another thing of potential use, maybe especially with the module site starting to update regularly?
Would be nice if we could abstract out how to figure out dependencies from different source - meta, index, or even local (the old approach that downloads modules one by one then grabs the next set of dependencies). Particularly if there are disagreements, since then we know something is wrong.
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.
This looks very promising - I haven't tested so not approving just yet, not sure if I'll have enough time for that tonight. Thanks for the updates @DarkWeird 👍
import groovy.json.JsonSlurper | ||
import org.terasology.cli.config.Config | ||
|
||
//TODO deps handling |
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.
Not really, meta modules are purely meant as raw asset containers and should never have dependencies
import picocli.CommandLine | ||
import picocli.CommandLine.Command | ||
import picocli.CommandLine.Mixin | ||
import picocli.CommandLine.Option | ||
import picocli.CommandLine.Parameters | ||
|
||
@Command(name = "get", description = "get module ") | ||
class GetCommand implements Runnable { |
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.
So if I'm looking at things right there are two GetCommand
classes, one common one module, and the one selected is simply based on the import statement? I guess that works but it looks scary to me :-)
If dependencies is the only unique way they differ, would it make sense to abstract out a ProvidesDependencies
interface or something with a method, and if during the get command setup we see that only then look at the dependency stuff? Then you could in theory support dependencies per type arbitrarily
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.
wonder what you gain by making this so abstract. trying to add additional layers to best fit the situation. just make more sense to implement this as case by case. The commands are where you implement the details. just make sense to implement them cases by case. wonder if some of this abstraction might add additional trouble down the line.
|
||
abstract ItemConfig getConfig() | ||
|
||
@Option(names = ["-origin", "-o"], description = "Github remote Organization/User to target") |
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.
If we're doing Linux style should this become --origin
?
I don't think we should be relying on |
This is starting to look a bit overly convoluted too me. It's way to clever for its own good and I think this will be difficult to add onto in the future. I would opt to shave away some of these abstractions and separate the details more between libs,modules, and faces and keep the codebase more functional. with some helper utilities for some common things to share. this is a CLI utility, why does it need to be so complicated and a lot of this complicated logic feels unwarranted. you've tightly coupled libs, meta, module together when the details of each are not that closely bound to each other. sure there is no duplication but that is in exchange for high coupling and complexity. I have no problem with proceeding with how this is written but I have some concessions with how this is put together at the moment. I kind of like what @skaldarnar has written: https://github.com/skaldarnar/node-gooey |
is there anything else? |
idk. :( |
I did have a brief look at this and played around with it for a bit. Here are my thoughts and notes:
Things I've tested:
A few other open questions:
tl;dr: I'd like to split this PR up into smaller chunks in get it merged step by step. |
there is no need to split the PR its self contained so it doesn't affect the existing cli tool. |
Our contributor guide asks the user to run
which does not work anymore with this PR. Thus, I don't follow the argument of this being "self-contained" and "not affecting the existing CLI tooling". In addition, as reported above, the replacement of exactly that comment threw an error when I tried it out. |
I'll roll back all the changes on the removed groovy code. should keep the old cli available, didn't realize I deleted it. |
6065983
to
d142b19
Compare
Squashed commit of the following: commit 89b591f Author: Cervator <[email protected]> Date: Fri Jul 10 22:55:01 2020 -0500 feat: working recurse command in the new style, misc cleanup and utility commit 85433d5 Author: Cervator <[email protected]> Date: Fri Jul 10 16:17:53 2020 -0500 chore: rename stuff, add package structure, tweak some comments, more recurse logic commit 53662ac Author: Cervator <[email protected]> Date: Thu Jul 9 23:23:05 2020 -0500 chore: adjust the Gradle-based GooeyCLI setup * Moves it to a maybe more sensible place in the gradle directory where the wrapper lives, this seems kinda related * Standardizes the source path so we don't need to explicitly configure it * Drops the Groovy dependency (in Gradle) down to match what's currently in the Gradle Wrapper (although it would still get fetched and used separately for any sort of GooeyCLI *build* process) commit c5ed6d3 Author: Michael <[email protected]> Date: Mon Jul 6 13:14:35 2020 -0700 correct synopsisSubcommandLabel commit fc46d27 Author: Michael <[email protected]> Date: Mon Jul 6 12:29:17 2020 -0700 add sourceset for cli config commit d9e2e18 Author: Cervator <[email protected]> Date: Sun Jul 5 22:59:08 2020 -0500 chore: fix path on Windows, avoid some warning about logging itself commit 4a9dc64 Author: Michael <[email protected]> Date: Sun Jul 5 20:35:35 2020 -0700 move CLI and added into package commit d21e82a Author: Cervator <[email protected]> Date: Sat Jul 4 15:09:45 2020 -0500 chore: Minor cleanup, plus bring back the module file Git thought was being deleted rather than replaced commit 05ca0f8 Author: Cervator <[email protected]> Date: Fri Jul 3 20:51:36 2020 -0500 feat: GooeyCLI - replacement utility scripting system based on PicoCLI. Still a proof of concept, with a limited amount of old functionality converted to showcase the new approach. Relies on a groovyw tweak, renames the scripts, and lets PicoCLI worry about all the CLI structuring
It provides bash-completion for `zsh` and `bash` also add a lot help for setup it.
* Use `Instant` for date-time of snapshot - one format for all and supports timezones * Use epoch seconds as filename for snapshots - most datetime formats contains illegal symbols for OSs
* reimplement algorithm. gather dependencies before git cloning. * parallel getting at x1.5-x4 faster then sequence getting
…nce) and move snapshot's commands to `gw workspace snapshot`
Co-authored-by: Rasmus Praestholm <[email protected]>
…dule/ExecuteCommand.groovy Co-authored-by: Rasmus Praestholm <[email protected]>
* Provide `Modules` static class for working with modules * extract Git commands for Items ( future update for facades, libs, metas) * Provide reformat groovys files
…nknown item handler
This reverts commit 9738982
…s. add unknown item handler" This reverts commit ba4077f
…onflict in hierarchy) make parallel on-demand recursive dep resolving
d142b19
to
f2f5b41
Compare
Here is an attempt to revive the gooey CLI tool. ended up cutting things down and trying to simplify things. I don't really like how the original groovy code tries to use inheritance to generalize an interface between facades, modules and libraries. I think they're diverse enough where this doesn't really make sense. I migrated in a couple of the commands which should cover most of our needs.
Original PR (with larger description): #4065