spf13 / cobra-cli Goto Github PK
View Code? Open in Web Editor NEWCobra CLI tool to generate applications and commands
License: Apache License 2.0
Cobra CLI tool to generate applications and commands
License: Apache License 2.0
Moving from spf13/cobra#1381
For example:
cobra add foo--bar--baz --var-name=foo_bar_bazCmd -p 'parentCmd'
// generates cmd/foo--bar--baz.go
Similarly, it'd be nice if I can run the cobra command in the current directory instead of the root repo directory, for example like:
~/workspace/my-cli/cmd/subcommand $ cobra add -p 'subcommandCmd' .
Currently, the user of the cli has to append 'Cmd' to the parent command name when adding a child command.
I believe it would be a small improvement in the user experience if the command name could be used directly, as the user does in other commands.
Current behaviour:
cobra-cli add config
cobra-cli add set -p 'configCmd'
Proposed behaviour:
cobra-cli add config
cobra-cli add set -p config
A possible solution is to have the add command append 'Cmd' to the given parent command name, similar to how commandName is validated.
Hi,
I'm running on command not found when installing the cli.
Steps I did:
go install github.com/spf13/cobra-cli@latest
~/.bashrc
contains $GOPATH: exportPATH="$PATH:/Users/daniperez/.local/bin:$GOPATH/bin"
source ~/.bashrc
I double checked and cobra-cli is present under go/bin
: cobra-cli controller-gen gopls
If it helps I'm running on a macOs Monterey v12.7.1
Am I doing something wrong?
I understand the filename is being camel-cased for a reason, but can't the command name still have the hyphen in the name?
cobra-cli add hello-world
, makes the file named helloWorld
Manually changing the Use
parameter to hello-world does change the command name to hello-world and works as intended without creating any issues with the file names..
Can we modify the command add
to include the hyphen in the Use
parameter and camel-case it everywhere else as usual? That will prevent users from manually changing the Use
parameter and the add command will work as intended!
Hi there!
I'm proposing a change to cobra-cli that would allow this command to find some way to make the tpl
package more customizable.
Use case:
We have a CLI that our dozen+ person team all contributes to in order to be more effective at our jobs. This has made this cobra CLI to become incredibly complex through organic growth. The way we declare our arguments has deviated from the base template that's provided, and we have extended the Command
interface to better suit our use case through inheritance. With those changes (which are slowly being rolled out to our codebase) I think it would be nice to be able to use this command utility with a custom template defined within our codebase for how a "new empty command" should look like, compared to our current workflow of copying a "simpler" command file, and trying to change all of the things to get it working.
Ideally - there would be some pre-defined directory or file within the root of a cobra-based project that would declare the templates, and then only if that file is present the cobra-cli
tool would automatically default to using that template for new commands rather than the one defined within the tpl package inside this repo.
I'm more than happy to work on building out this feature, if you like the idea.
Thanks for your consideration,
Kirk
It would better to provide a new version
sub command to cobra-cli:
Actual:
$ cobra-cli version
Error: unknown command "version" for "cobra-cli"
$ cobra-cli --version
Error: unknown flag: --version
Wdyt?
In support of spf13/cobra#1597, we want to tag this repository with the same "version" that was used before we migrated the code here. This still communicates the version of the cobra CLI but also represents the final tag that the two will correlate.
In otherwords, this tag is the split in the road that will enable use to seperate cobra
from cobra-cli
The release note for v1.3.0
of this repo will note that all previous history and release markers can be tracked in the spf13/cobra
repo.
If there are no objections, I will do this within the week ๐
When attempting to use cobra-cli init
in a project that uses Go 1.18's new workspace mode, I hit what looks like a JSON unmarshaling error (Error: invalid character '{' after top-level value
) and initializing fails.
My apologies in advance if I'm misunderstanding any aspect of workspaces, modules, or cobra-cli here - I'm fairly new to Go, but expecting this might be a new edge case in 1.18 due to workspaces.
mkdir cli-playground && cd cli-playground
go work init
mkdir project1 && cd project1 && go mod init project1 && cd ..
mkdir project2 && cd project2 && go mod init project2 && cd ..
go work use project1 project2
cd project2
cobra-cli init
#=> go: creating new go.mod: module project1
#=> go: creating new go.mod: module project2
#=> Error: invalid character '{' after top-level value
I believe this is because go list -json -m
returns a stream of JSON objects with relevant modules, whereas this bit of code expects to consume a single JSON object.
I spiked out a test in investigating this behavior, which exposes the same behavior as above. But Iโm guessing that approach only works for Go 1.18+, and cobra-cli probably wants to support earlier versions. As far as a fix (if we agree it's worth addressing), I was thinking that the parseModInfo
operations could potentially allow using the current directory (from the output of go list -json -e
) to decide which of the JSON objects to use. Thoughts?
Removing all projects from the workspace except the one I want to cobra-cli init
does let things work, and that's good enough to unblock me.
In experimenting with removing workspace items, there's another case that has surprising (to me) behavior: if we try running cobra-cli init
on a module that's not yet included in the workspace.
mkdir cli-playground && cd cli-playground
go work init
mkdir project1 && cd project1 && go mod init project1 && cd ..
mkdir project2 && cd project2 && go mod init project2 && cd ..
go work use project1
cd project2
cobra-cli init
The above appears to succeed, but the contents of project2/main.go
are now:
/*
Copyright ยฉ 2022 NAME HERE <EMAIL ADDRESS>
*/
package main
import "project1/tmp/cli-playground/project2/cmd"
func main() {
cmd.Execute()
}
I'm honestly not sure what behavior I'd expect here, since the module isn't in the workspace. But the import path project1/tmp/cli-playground/project2/cmd
looks pretty wrong to me (note both project1
and project2
in that path, despite them being peers). I can totally understand this scenario being unsupported / undefined behavior,
But I thought it could be useful to include it in this report, both because I think the existing behavior is kind of surprising (I might personally prefer an error), and more importantly because I imagine that the choice of which module to pick from the list in go list -json -m
could potentially create better behavior here.
......
Args: cobra.MatchAll(cobra.MinimumNArgs(2), cobra.OnlyValidArgs),
Run: cropCmdRun,
}
.....
func cropCmdRun(cmd *cobra.Command, args []string) {
fmt.Println("crop calling .....")
fmt.Printf("args :%v \n", spew.Sdump(args))
......
build the source and run like follow:
utils.exe crop -s=src.png -c=i.cvs
Error: requires at least 2 arg(s), only received 0
Usage:
utils crop [flags]
......
if remove the MinimumNArgs like this :
...
Args: cobra.MatchAll(cobra.OnlyValidArgs),
...
build and run like follow:
utils.exe crop -s=src.png -c=i.cvs
crop calling .....
args :([]string) (cap=2) {
}
Hey, I am trying to call a command with a specific flag from another command but I've been struggling to make it work. Here is what I am doing:
var startCmd = &cobra.Command{
Use: "start",
Short: "The central command for the CLI.",
Long: `start can execute any of the other commands in the CLI.`,
Run: func(cmd *cobra.Command, args []string) {
getCmd.SetArgs([]string{"--data", "price"})
getCmd.Run(cmd, os.Args[1:])
// getCmdRun(cmd, []string{"--data", "price"}) -> tried this as well but failed too
},
}
func init() {
rootCmd.AddCommand(startCmd)
startCmd.AddCommand(getCmd)
}
Each time it raises a warning from the getCmd
command saying my flag is not recognized. How do we do that?
Just trying to install this on my M1 Mac, and it keeps giving me this error:
go: github.com/spf13/cobra-cli@latest: module github.com/spf13/cobra-cli@latest found (v1.3.0), but does not contain package github.com/spf13/cobra-cli
The command I'm running is a copy/paste from the readme: go install github.com/spf13/cobra-cli@latest
I'm running Sonoma 14.2, with iTerm Build 3.4.22 and Zsh 5.9 (x86_64-apple-darwin23.0). I checked the previous issues, followed what they said, but to no avail! So... what am I doing wrong?
Thanks!
mkdir myapp
cd myapp
go mod init github.com/spf13/myapp
go get -u github.com/spf13/cobra@latest
go install github.com/spf13/cobra-cli@latest
When I excute cobra-cli init
, -bash: cobra-cli: command not found
windows system: 'cobra-cli' is not recognized as an internal or external command,
operable program or batch file.
why๏ผ A month ago is normal!
When run in an existing project, cobra-cli init
will silently overwrite an existing main.go
.
In this situation, cobra-cli
should emit an error and exit without making changes rather than overwriting existing code.
Now that #1 is merged, a Test CI job is defined, and it is green on main
, it should be marked a required job to prevent accidental merges without first passing tests
Looks like a regression that was previously fixed has been reintroduced between 1.2.1
and 1.3.0
and effects 1.4.0
and then got migrated along to this new repository. I get an error when I try to specify a custom license.
Error: unknown license: /Users/paul/.my-license.yaml
I have a template that I use for my license, here is an example of what it looks like:
To recreate:
$ go install github.com/spf13/cobra-cli@latest
$ mkdir example
$ cd example
$ go mod init example
$ cobra-cli init --license ~/.my-license.yaml
> Error: unknown license: /Users/paul/.my-license.yaml
How to make the following WARNING gone?
godror WARNING: discrepancy between DBTIMEZONE ("+00:00"=0) and SYSTIMESTAMP ("-05:00"=-500) - set connection timezone, see https://github.com/godror/godror/blob/master/doc/timezone.md
I tried to play with Timezone in CommonParms, don't know if this is right place to set up something and if so what correct value here
``
39 CommonParams: dsn.CommonParams{
40 Username: p_username,
41 Password: dsn.NewPassword(p_password),
42 ConnectString: connString,
43 // Timezone: time.FixedZone("UTC-5", -55050), // need to figure out what is the correct value
mkdir -p cobra
cd cobra
cobra-cli init --viper demo
$ cat demo/main.go
/*
Copyright ยฉ 2023 NAME HERE <EMAIL ADDRESS>
*/
package main
import "github.con/cuizhaoyue/go-demo/cobra/cmd"
func main() {
cmd.Execute()
}
github.con/cuizhaoyue/go-demo/cobra/demo/cmd
rather than
github.con/cuizhaoyue/go-demo/cobra/cmd
cobra-cli
version is the latest version as of 2023-03-04Multiple issues in the spf13/cobra repo were regarding the patterns of globals/init methods which made testing and growth difficult.
This linked issue properly points to the method (I think) most people eventually figure out for themselves.
Moved to this repo due to the CLI being split off.
e.g:
run cobra-cli add get, it will generate cmd/get.go
run cobra-cli add config, it will generate cmd/config.go
run cobra-cli add get -p 'configCmd', it will also generate cmd/get.go
the thrid command will overwrite cmd/get.go
finally, we can't have 'app get ' and 'app config get ' two commands at the same time.
Hi.
It seems the code completion is not working in zsh
environment.
Apple M1 Pro with macOS Monterey 12.5.1
mkdir myapp
cd myapp
go mod init myapp
cobra-cli init
cobra-cli add serve
go build .
./myapp completion zsh > /tmp/completion
source /tmp/completion
now, try to complete:
./myapp se[TAB]
nothing is completed after hitting TAB (even multiple hits), but it should complete the serve
command.
#compdef myapp
# zsh completion for myapp -*- shell-script -*-
__myapp_debug()
{
local file="$BASH_COMP_DEBUG_FILE"
if [[ -n ${file} ]]; then
echo "$*" >> "${file}"
fi
}
_myapp()
{
local shellCompDirectiveError=1
local shellCompDirectiveNoSpace=2
local shellCompDirectiveNoFileComp=4
local shellCompDirectiveFilterFileExt=8
local shellCompDirectiveFilterDirs=16
local lastParam lastChar flagPrefix requestComp out directive comp lastComp noSpace
local -a completions
__myapp_debug "\n========= starting completion logic =========="
__myapp_debug "CURRENT: ${CURRENT}, words[*]: ${words[*]}"
# The user could have moved the cursor backwards on the command-line.
# We need to trigger completion from the $CURRENT location, so we need
# to truncate the command-line ($words) up to the $CURRENT location.
# (We cannot use $CURSOR as its value does not work when a command is an alias.)
words=("${=words[1,CURRENT]}")
__myapp_debug "Truncated words[*]: ${words[*]},"
lastParam=${words[-1]}
lastChar=${lastParam[-1]}
__myapp_debug "lastParam: ${lastParam}, lastChar: ${lastChar}"
# For zsh, when completing a flag with an = (e.g., myapp -n=<TAB>)
# completions must be prefixed with the flag
setopt local_options BASH_REMATCH
if [[ "${lastParam}" =~ '-.*=' ]]; then
# We are dealing with a flag with an =
flagPrefix="-P ${BASH_REMATCH}"
fi
# Prepare the command to obtain completions
requestComp="${words[1]} __complete ${words[2,-1]}"
if [ "${lastChar}" = "" ]; then
# If the last parameter is complete (there is a space following it)
# We add an extra empty parameter so we can indicate this to the go completion code.
__myapp_debug "Adding extra empty parameter"
requestComp="${requestComp} \"\""
fi
__myapp_debug "About to call: eval ${requestComp}"
# Use eval to handle any environment variables and such
out=$(eval ${requestComp} 2>/dev/null)
__myapp_debug "completion output: ${out}"
# Extract the directive integer following a : from the last line
local lastLine
while IFS='\n' read -r line; do
lastLine=${line}
done < <(printf "%s\n" "${out[@]}")
__myapp_debug "last line: ${lastLine}"
if [ "${lastLine[1]}" = : ]; then
directive=${lastLine[2,-1]}
# Remove the directive including the : and the newline
local suffix
(( suffix=${#lastLine}+2))
out=${out[1,-$suffix]}
else
# There is no directive specified. Leave $out as is.
__myapp_debug "No directive found. Setting do default"
directive=0
fi
__myapp_debug "directive: ${directive}"
__myapp_debug "completions: ${out}"
__myapp_debug "flagPrefix: ${flagPrefix}"
if [ $((directive & shellCompDirectiveError)) -ne 0 ]; then
__myapp_debug "Completion received error. Ignoring completions."
return
fi
local activeHelpMarker="_activeHelp_ "
local endIndex=${#activeHelpMarker}
local startIndex=$((${#activeHelpMarker}+1))
local hasActiveHelp=0
while IFS='\n' read -r comp; do
# Check if this is an activeHelp statement (i.e., prefixed with $activeHelpMarker)
if [ "${comp[1,$endIndex]}" = "$activeHelpMarker" ];then
__myapp_debug "ActiveHelp found: $comp"
comp="${comp[$startIndex,-1]}"
if [ -n "$comp" ]; then
compadd -x "${comp}"
__myapp_debug "ActiveHelp will need delimiter"
hasActiveHelp=1
fi
continue
fi
if [ -n "$comp" ]; then
# If requested, completions are returned with a description.
# The description is preceded by a TAB character.
# For zsh's _describe, we need to use a : instead of a TAB.
# We first need to escape any : as part of the completion itself.
comp=${comp//:/\\:}
local tab="$(printf '\t')"
comp=${comp//$tab/:}
__myapp_debug "Adding completion: ${comp}"
completions+=${comp}
lastComp=$comp
fi
done < <(printf "%s\n" "${out[@]}")
# Add a delimiter after the activeHelp statements, but only if:
# - there are completions following the activeHelp statements, or
# - file completion will be performed (so there will be choices after the activeHelp)
if [ $hasActiveHelp -eq 1 ]; then
if [ ${#completions} -ne 0 ] || [ $((directive & shellCompDirectiveNoFileComp)) -eq 0 ]; then
__myapp_debug "Adding activeHelp delimiter"
compadd -x "--"
hasActiveHelp=0
fi
fi
if [ $((directive & shellCompDirectiveNoSpace)) -ne 0 ]; then
__myapp_debug "Activating nospace."
noSpace="-S ''"
fi
if [ $((directive & shellCompDirectiveFilterFileExt)) -ne 0 ]; then
# File extension filtering
local filteringCmd
filteringCmd='_files'
for filter in ${completions[@]}; do
if [ ${filter[1]} != '*' ]; then
# zsh requires a glob pattern to do file filtering
filter="\*.$filter"
fi
filteringCmd+=" -g $filter"
done
filteringCmd+=" ${flagPrefix}"
__myapp_debug "File filtering command: $filteringCmd"
_arguments '*:filename:'"$filteringCmd"
elif [ $((directive & shellCompDirectiveFilterDirs)) -ne 0 ]; then
# File completion for directories only
local subdir
subdir="${completions[1]}"
if [ -n "$subdir" ]; then
__myapp_debug "Listing directories in $subdir"
pushd "${subdir}" >/dev/null 2>&1
else
__myapp_debug "Listing directories in ."
fi
local result
_arguments '*:dirname:_files -/'" ${flagPrefix}"
result=$?
if [ -n "$subdir" ]; then
popd >/dev/null 2>&1
fi
return $result
else
__myapp_debug "Calling _describe"
if eval _describe "completions" completions $flagPrefix $noSpace; then
__myapp_debug "_describe found some completions"
# Return the success of having called _describe
return 0
else
__myapp_debug "_describe did not find completions."
__myapp_debug "Checking if we should do file completion."
if [ $((directive & shellCompDirectiveNoFileComp)) -ne 0 ]; then
__myapp_debug "deactivating file completion"
# We must return an error code here to let zsh know that there were no
# completions found by _describe; this is what will trigger other
# matching algorithms to attempt to find completions.
# For example zsh can match letters in the middle of words.
return 1
else
# Perform file completion
__myapp_debug "Activating file completion"
# We must return the result of this command, so it must be the
# last command, or else we must store its result to return it.
_arguments '*:filename:_files'" ${flagPrefix}"
fi
fi
fi
}
# don't run the completion function when being source-ed or eval-ed
if [ "$funcstack[1]" = "_myapp" ]; then
_myapp
fi
Is this a bug, or am I doing something wrong? ๐
TIA
cobra-cli init --viper
Your Cobra application is ready at ...
sudo docker build -t bin . && sudo docker run -it --rm bin
Step 1/3 : FROM scratch
--->
Step 2/3 : COPY ${PWD}/bin .
---> f18dcc8e0e25
Step 3/3 : ENTRYPOINT ["./bin"]
---> Running in dc5fd26d812f
Removing intermediate container dc5fd26d812f
---> ee78f634bd9f
Successfully built ee78f634bd9f
Successfully tagged bin:latest
exec ./bin: no such file or directory
FROM scratch
COPY ${PWD}/bin .
ENTRYPOINT ["./bin"]
debian and local is fine
golang: 1.18.2
cobra: 1.4.0
viper: 1.11.0
When running cobra-cli init
on an existing project with a main.go
, it will overwrite the main.go
. I don't think this behavior should be a default. Could we add functionality to at least move the old file to something like main.go.old
?
This is transfer of @fanux's spf13/cobra#1059 as suggested there by @johnSchnake
โ app cobra add create
create created at /Users/fanux/work/src/app/cmd/create.go
โ app cobra add user -p create
user created at /Users/fanux/work/src/app/cmd/user.go
โ app tree
.
โโโ LICENSE
โโโ cmd
โย ย โโโ create.go
โย ย โโโ root.go
โย ย โโโ user.go
โโโ main.go
cobra generates subcommand user
in the same dir of its parent dir, it not very nice.
If I add a command user
this user command is not create
subcommand:
cobra add user
Error: /Users/fanux/work/src/app/cmd/user.go already exists
So I think, create
subcommand in a sub dir is better, like this:
.
โโโ LICENSE
โโโ cmd
โย ย โโโ create.go
โย ย โโโ root.go
| |---create
โย ย โโโ user.go
โโโ main.go
This will not conflict
Running
cobra-cli completion bash
Displays
Using config file: ~/.cobra.yaml
This isn't causing an issue, but it's a bit of a cosmetic annoyance, especially since I have source <(cobra-cli completion bash)
. This text displays every time I open a new terminal tab.
Is there a way to suppress it?
running tests
=== RUN TestGoldenAddCmd
add_test.go:28: "/build/source/cmd/testproject/cmd/test.go" and "testdata/test.go.golden" are not equal!
$ diff -u /build/source/cmd/testproject/cmd/test.go testdata/test.go.golden
--- /build/source/cmd/testproject/cmd/test.go 2023-01-19 16:36:00.335867015 +0000
+++ testdata/test.go.golden 1970-01-01 00:00:01.000000000 +0000
@@ -1,5 +1,5 @@
/*
-Copyright ยฉ 2023 NAME HERE <EMAIL ADDRESS>
+Copyright ยฉ 2022 NAME HERE <EMAIL ADDRESS>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
exit status 1
--- FAIL: TestGoldenAddCmd (0.00s)
=== RUN TestValidateCmdName
--- PASS: TestValidateCmdName (0.00s)
=== RUN TestGoldenInitCmd
=== RUN TestGoldenInitCmd/successfully_creates_a_project_based_on_module
init_test.go:77: "/build/source/cmd/testproject/main.go" and "testdata/main.go.golden" are not equal!
$ diff -u /build/source/cmd/testproject/main.go testdata/main.go.golden
--- /build/source/cmd/testproject/main.go 2023-01-19 16:36:00.515874546 +0000
+++ testdata/main.go.golden 1970-01-01 00:00:01.000000000 +0000
@@ -1,5 +1,5 @@
/*
-Copyright ยฉ 2023 NAME HERE <EMAIL ADDRESS>
+Copyright ยฉ 2022 NAME HERE <EMAIL ADDRESS>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
exit status 1
--- FAIL: TestGoldenInitCmd (0.18s)
--- FAIL: TestGoldenInitCmd/successfully_creates_a_project_based_on_module (0.18s)
FAIL
FAIL github.com/spf13/cobra-cli/cmd 0.187s
FAIL
/cc nixpkgs maintainer @ivankovnatsky
The following is a living issue, pinned to the top of cobra-cli
's GitHub issues for wide visibility, available for comment, that represents the current labeling, triaging, milestone, and maintenance state of cobra-cli
. Maintainers, contributors, and users may refer to this in order to understand how bugs and features are being triaged and where their feature request may be in the maintenance cycle.
Inspired by projects like kubernetes-sigs/cluster-api
, helm/helm
and spf13/cobra
kind/
- The type of issuekind/bug
: A bug in cobra-cli
; unintended behaviorkind/feature
: A feature request for cobra-cli
; new or enhanced behaviorkind/documentation
: Documentation of cobra-cli
itselfkind/testing
: CI/CD, testing, etc. for cobra-cli
. Usually also gets the github labelkind/rel-eng
: Related to tagging and releasing cobra-cli
kind/upstream
: Go modules cobra-cli
depends onkind/security
: Related to security of cobra-cli
itself. Refer to the security policy before opening any public issue.kind/cleanup
: General cleanup of code, issues, etc.kind/deprecation
: Related to a feature or part of code being deprecatedkind/support
: Questions, supporting users, etc.area/
- The area of work that needs to be executed againstarea/cobra-cli
: Core functionality of cobra-cli
area/go
: General Go, like go.mod
or go.sum
changesarea/github
: For changes to Github specific things not shipped in the library (like maintainers files, actions, etc)area/licenses
: Changes to license functionalitytriage/
- The state of an issue being triagedtriage/needs-triage
: Needs to be placed into a milestone, or be closed by maintainers. This label is removed once placed into a milestone.triage/blocked
: Cannot move forward until some roadblock is liftedtriage/needs-info
: An issue that needs more investigation from maintainers or more info from the issue providertriage/duplicate
: A duplicate issue. These issues are usually closed after receiving this label.lifecycle/
- Where something is at in it's lifecyclelifecycle/needs-cla
: The CLA still needs to be signed by the PR author. This label is blocking until the CLA is signed.lifecycle/active
: Actively being worked on by a community member or maintainer. This label should generally also correspond with someone being assigned to an issuelifecycle/needs-proposal
: For large features / bugs that need a proposal and community buy inlifecycle/approved
: For large features / bugs that have a proposal and have community buy inlifecycle/needs-pr
: Ready for a PR from the communitylifecycle/stale
: Labeled by GitHub actions after 30 days of inactivitylifecycle/rotten
: Labeled by GitHub actions after 30 days of having the lifecycle/stale
label. Issues and PRs with this label will close after another 30 days of inactivity.lifecycle/frozen
: Prevents GitHub actions from labeling Issues and PRs with lifecycle/stale
or lifecycle/rotten
lifecycle/wont-do
: For issues and PRs the community has determined are not a priority and will not execute againstsize/
- The size of the PRUtilizes the pr-size-labeler
to label PRs with a given size per number of lines changed
size/XS
: Denotes a PR that changes 0-9 linessize/S
: Denotes a PR that changes 10-24 linessize/M
: Denotes a PR that changes 24-99 linessize/L
: Denotes a PR that changes 100-199 linessize/XL
: Denotes a PR that changes 200 or more lines. Note: An XL pull request exceeds the recommended size of changes in a single PR. This is fine, but needs special attention from maintainers and may be rejected due to it's size. Make sure you are not addressing multiple issues in a single PR.lgtm
: Denotes "looks good to me" from maintainers and signals other collaborators that a PR is ready for additional review and mergegood-first-issue
: A good issue for a new collaborator to tacklehelp-wanted
: An issue that the maintainers would like help onadmin
: For general admin tasks to be done usually by maintainersMilestones are used to categorize work and contributions into specific releases.
next
milestone is used as a catch all for work that is being planned for some arbitrary upcoming release by the communityicebox
milestone is used to track things that may need to be executed against eventually but are blocked, have the lifecycle/frozen
label, etc.cobra-cli
has no release cadence but attempts to release quarterly alongside when cobra
itself is released.
This is a best effort.
Generally, a pinned release tracker issue is made that corresponds with the current release. On release, tags will be made on GitHub that than can be consumed by downstream Go modules.
The cobra-cli
follows Semantic Versioning. This generally means that:
v1.x.x
to v2.x.x
) have breaking changes (like deprecations, changing APIs, etc). Users of cobra
will need to do some work to update their Go code to consume the latest major versionv1.1.x
to 1.2.x
) have no breaking changes, but include new features. Users of cobra
will not need to do work to update their Go code to consume the latest minor version, but may choose to use the new features.v1.1.1
to v1.1.2
) do not include new features or breaking changes but only backwards compatible bug fixes. Users of cobra
will not need to do work to update their Go code to consume the latest patch version.For more details, please refer to the Cobra User Contract
It's currently `Add (cobra add) will create a new command, with a license and
the appropriate structure for a Cobra-based CLI application,
and register it to its parent (default rootCmd).
If you want your command to be public, pass in the command name
with an initial uppercase letter.
Example: cobra add server -> resulting in a new cmd/server.go`
This needs to be modified according to "cobra-cli" i.e. cobra add server -> cobra-cli add server
Similar changes are required everywhere.
Error using "cobra-cli ini" --> Error: invalid character '{' after top-level value
Go version : 1.18.1
VsCode : 1.66.1
It'd be neat if cobra didn't touch an already existing LICENCE file. I have to revert changes every time I use cobra.
Hi, noob here. I have been trying to learn to use cobra, all the tutorials uses --pkg-name flag. However when I use it like this
cobra-cli init --pkg-name=github.com/samozturk/randompackage
it says Error: unknown flag: --pkg-name Usage: cobra-cli init [path] [flags]
Are these tutorials outdated or am I doing something wrong?
say I have commands hosts
and services
and I want them both to have a subcommand list
, how would I do that with cobra-cli
?
# cobra-cli init --viper cli
# cobra-cli add genConf
Error: open C:\Users\xxx\cli/cmd/genConf.go: The system cannot find the path specified.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.