Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 2118712

Browse files
committedJan 18, 2025·
Merge branch 'main' of ssh://github.com/viamrobotics/rdk into sean-pr
2 parents edcbe9d + 4f2b707 commit 2118712

22 files changed

+1444
-675
lines changed
 

‎.github/CODEOWNERS

+3
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,6 @@
11
# Team SDK is responsible for CLI best practices and wishes to maintain insight into any
22
# changes currently being made to the CLI codebase.
33
/cli/app.go @viamrobotics/sdk-netcode
4+
/cli/CONTRIBUTING.md @viamrobotics/sdk-netcode
5+
/cli/STYLEGUIDE.md @viamrobotics/sdk-netcode
6+

‎.github/workflows/test-module-generation.yml

+22-23
Original file line numberDiff line numberDiff line change
@@ -13,29 +13,29 @@ jobs:
1313
language: ["python", "go"]
1414
resource:
1515
[
16-
{ subtype: "arm", type: "component" },
17-
{ subtype: "audio_input", type: "component" },
18-
{ subtype: "base", type: "component" },
19-
{ subtype: "board", type: "component" },
20-
{ subtype: "camera", type: "component" },
21-
{ subtype: "encoder", type: "component" },
22-
{ subtype: "gantry", type: "component" },
23-
{ subtype: "generic", type: "component" },
24-
{ subtype: "gripper", type: "component" },
25-
{ subtype: "input", type: "component" },
26-
{ subtype: "motor", type: "component" },
27-
{ subtype: "movement_sensor", type: "component" },
28-
{ subtype: "pose_tracker", type: "component" },
29-
{ subtype: "power_sensor", type: "component" },
30-
{ subtype: "sensor", type: "component" },
31-
{ subtype: "servo", type: "component" },
16+
{ subtype: "arm" },
17+
{ subtype: "audio_input" },
18+
{ subtype: "base" },
19+
{ subtype: "board" },
20+
{ subtype: "camera" },
21+
{ subtype: "encoder" },
22+
{ subtype: "gantry" },
23+
{ subtype: "generic_component" },
24+
{ subtype: "gripper" },
25+
{ subtype: "input" },
26+
{ subtype: "motor" },
27+
{ subtype: "movement_sensor" },
28+
{ subtype: "pose_tracker" },
29+
{ subtype: "power_sensor" },
30+
{ subtype: "sensor" },
31+
{ subtype: "servo" },
3232

33-
{ subtype: "generic", type: "service" },
34-
{ subtype: "mlmodel", type: "service" },
35-
{ subtype: "motion", type: "service" },
36-
{ subtype: "navigation", type: "service" },
37-
{ subtype: "slam", type: "service" },
38-
{ subtype: "vision", type: "service" },
33+
{ subtype: "generic-service" },
34+
{ subtype: "mlmodel" },
35+
{ subtype: "motion" },
36+
{ subtype: "navigation" },
37+
{ subtype: "slam" },
38+
{ subtype: "vision" },
3939
]
4040
steps:
4141
- name: Checkout Code
@@ -53,7 +53,6 @@ jobs:
5353
--language "${{ matrix.language }}" \
5454
--public-namespace "my-org" \
5555
--resource-subtype "${{ matrix.resource.subtype }}" \
56-
--resource-type "${{ matrix.resource.type }}" \
5756
--model-name "model-name" \
5857
--dry-run
5958

‎cli/CONTRIBUTING.md

+55
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
# Contributing
2+
3+
Contributions to the Viam CLI are always welcome and appreciated! Every bit helps, and
4+
credit will always be given.
5+
6+
## Types of Contributions
7+
8+
### Report Bugs
9+
10+
If you are reporting a bug, please include:
11+
12+
- Your operating system name and version.
13+
- Which version of the viam CLI you are using (viewable with command `viam version`)
14+
- Any details about your local setup that might be helpful in troubleshooting.
15+
- The observed behavior.
16+
- Detailed steps to reproduce the bug.
17+
18+
### Fix Bugs
19+
20+
Look through the GitHub issues for bugs. Anything tagged with "bug" and "help
21+
wanted" is open to whoever wants to implement it.
22+
23+
### Implement Features
24+
25+
Look through the GitHub issues for features. Anything tagged with "enhancement"
26+
and "help wanted" is open to whoever wants to implement it. When contributing, please
27+
consult the [style guide](STYLEGUIDE.md) to ensure consistency within the codebase.
28+
29+
### Write Documentation
30+
31+
You can never have enough documentation! Please feel free to contribute to any
32+
part of the documentation, such as the official docs, docstrings, or even
33+
on the web in blog posts, articles, and such.
34+
35+
### Submit Feedback
36+
37+
If you are proposing a feature:
38+
39+
- Explain in detail how it would work.
40+
- Keep the scope as narrow as possible, to make it easier to implement.
41+
42+
## Get Started!
43+
44+
Ready to contribute? You can follow the instructions in [README.md](README.md) to install and develop
45+
the viam CLI tool.
46+
47+
## Pull Request Guidelines
48+
49+
Before you submit a pull request, check that it meets these guidelines:
50+
51+
1. The pull request should include additional tests if appropriate.
52+
2. If the pull request adds functionality, the docs should be updated.
53+
3. The pull request should work for all currently supported operating systems and versions of Python.
54+
55+

‎cli/STYLEGUIDE.md

+188
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,188 @@
1+
# Code Style
2+
3+
Thank you for contributing to the Viam CLI! Please keep in mind the following best practices
4+
when structuring your code.
5+
6+
## Make Arguments Typeful
7+
Your CLI command's action func should be constructed with `createCommandWithT` and should put
8+
all command line argument values in a typed struct. This ensures type correctness and reduces
9+
the risks associated with having contributors manually parse args in each function they write.
10+
11+
### Examples
12+
<details>
13+
<summary>Good:</summary>
14+
15+
```golang
16+
type fooArgs struct {
17+
Bar int
18+
Baz string
19+
}
20+
21+
func fooAction(ctx cli.Context, args foo) error {
22+
bar := args.Bar
23+
baz := args.Baz
24+
...
25+
}
26+
27+
...
28+
29+
cli.Command{
30+
...
31+
Flags: []cli.Flag{
32+
&cli.StringFlag{
33+
Name: Baz,
34+
},
35+
&cli.IntFlag{
36+
Name: Bar,
37+
},
38+
},
39+
Action: createCommandWithT[fooArgs](fooAction),
40+
...
41+
}
42+
```
43+
</details>
44+
45+
<details>
46+
<summary>Bad:</summary>
47+
48+
```golang
49+
func fooAction(ctx cli.Context) error {
50+
bar := ctx.Int("Bar")
51+
baz := ctx.String("Baz)
52+
...
53+
}
54+
55+
...
56+
57+
cli.Command{
58+
Flags: []cli.Flag{
59+
&cli.StringFlag{
60+
Name: BazFlag,
61+
},
62+
&cli.IntFlag{
63+
Name: BarFlag,
64+
},
65+
},
66+
Action: fooAction,
67+
...
68+
}
69+
```
70+
</details>
71+
72+
## Avoid Flag Bloat
73+
We have a significant number of flags in the CLI already, many of which (e.g., `organization` or
74+
`location`) are used in multiple functions. Instead of adding duplicate flags, prefer reusing
75+
existing flags. If necessary, rename then to indicate their more generic usage.
76+
77+
### Example
78+
<details>
79+
<summary>Good:</summary>
80+
81+
```diff
82+
-const yourSpecialFlag = "some-cool-flag"
83+
+const generalSpecialFlag = "some-cool-flag"
84+
```
85+
</details>
86+
87+
<details>
88+
<summary>Bad:</summary>
89+
90+
```golang
91+
const yourSpecialFlag = "some-cool-flag"
92+
...
93+
const mySpecialFlag = "some-cool-flag"
94+
```
95+
</details>
96+
97+
## Hide Help From Commands With Subcommands
98+
When a parent level command with child commands exists (e.g., `viam organizations` has `list`,
99+
`logo`, `api-key`, and others as child commands), it makes little sense to show a `help` command
100+
since the parent level command doesn't do anything on its own.
101+
102+
### Example
103+
<details>
104+
<summary>Necessary diff:</summary>
105+
106+
```diff
107+
cli.Command{
108+
...
109+
Name: "my-parent-command",
110+
+ HideHelpCommand: true,
111+
Subcommands: []*cli.Command{
112+
{
113+
Name: "my-child-command1",
114+
...
115+
},
116+
{
117+
Name: "my-child-command2",
118+
...
119+
},
120+
},
121+
}
122+
```
123+
</details>
124+
125+
## Create Usage Text With Helper Func, Only Specify Required Args
126+
When creating usage text for a CLI command, use the `createUsageText` convenience method
127+
to generate text. Be sure to provide the fully qualified command (less `viam`) as your first
128+
argument, and only include actually required flags in the `requiredFlags` argument.
129+
130+
Additionally, be sure to use the `formatAcceptedValues` convenience method for defining usage
131+
text on a flag where only a discrete set of values are permitted.
132+
133+
### Example
134+
<details>
135+
<summary>Diff:</summary>
136+
137+
```diff
138+
cli.Command{
139+
...
140+
Name: "my-parent-command",
141+
Subcommands: []*cli.Command{
142+
Name: "my-child-command",
143+
Flags: []cli.Flag{
144+
&cli.StringFlag{
145+
Name: requiredFlag,
146+
Required: true,
147+
+ Usage: formatAcceptedValues("passes some required value", 'foo', 'bar, 'baz')
148+
- Usage: "passes some required value. must be either 'foo', 'bar', or 'baz'"
149+
},
150+
&cli.StringFlag{
151+
Name: optionalFlag,
152+
},
153+
},
154+
+ UsageText: createUsageText("my-parent-command my-child-command", []string{requiredFlag}, true, false),
155+
- UsageText: createUsageText("my-child-command", []string{requiredFlag, optionalFlag}, false, false),
156+
...
157+
}
158+
}
159+
```
160+
</details>
161+
162+
## Use `DefaultText` Field For Defining Default values
163+
Instead of adding extra text to the description of what a field does, we should use the automated
164+
formatting provided by the `DefaultText` field.
165+
166+
### Examples
167+
<details>
168+
<summary>Good:</summary>
169+
170+
```golang
171+
cli.StringFlag{
172+
Name: fooFlag,
173+
Usage: "sets value of Foo",
174+
DefaultText: "foo",
175+
}
176+
```
177+
</details>
178+
179+
<details>
180+
<summary>Bad:</summary>
181+
182+
```golang
183+
cli.StringFlag{
184+
Name: fooFlag,
185+
Usage: "sets value of Foo (defaults to foo)",
186+
}
187+
```
188+
</details>

0 commit comments

Comments
 (0)
Please sign in to comment.