Skip to content
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

Allow consuming cobra as a library without picking up viper dependencies #1597

Closed
liggitt opened this issue Feb 8, 2022 · 47 comments
Closed
Milestone

Comments

@liggitt
Copy link
Contributor

liggitt commented Feb 8, 2022

Status

  1. https://github.com/spf13/cobra-cli has been created with an extracted copy of github.com/spf13/cobra/cobra/...
  2. Initialize cobra-cli repo cobra-cli#1 renamed the command to cobra-cli
  3. https://github.com/spf13/cobra-cli/releases/tag/v1.3.0, matching github.com/spf13/cobra v1.3.0 (except for the binary name)
  4. PRs to update public references to cobra/cobra in go imports and scripted references
  5. Remove CLI from this repo and update this repo's readme:

(original description follows)

First, many thanks for such a useful command library. The widespread adoption demonstrates how useful it is. A consequence of being very popular is that any dependencies of this module are picked up as transitive dependencies by a lot of consumers. The github.com/spf13/viper dependency of the cobra command line tool is particularly problematic, as it pulls in large numbers of large dependencies.

It would greatly help downstream consumers if this library could be consumed without picking up the viper dependencies.


History

Relevant existing issues:

There was a prior attempt at isolating the CLI command and viper dependency via a submodule:

That resulted in the following issues:

There were a few problems with the previous attempt:

  • No new tag was created for github.com/spf13/cobra once the submodule was created, so the @latest version of both github.com/spf13/cobra and github.com/spf13/cobra/cobra provided the github.com/spf13/cobra/cobra import path. This caused the "ambiguous import" error
  • The submodule used a local filesystem replace ... => ../ directive, which would break go get github.com/spf13/cobra/cobra and go install github.com/spf13/cobra/cobra@latest

Proposal

2022-03-10 note: rather than the approach proposed here, the Cobra CLI was split to a separate repo at https://github.com/spf13/cobra-cli. See discussion starting at #1597 (comment)

Possible solutions for reorganizing this library to isolate the viper dependency are discussed in #1240. I agree with @spf13 that we should avoid solutions that disrupt current consumers of the github.com/spf13/cobra import path.

I think the previous attempt to create a dedicated module for the cobra command packages (github.com/spf13/cobra/cobra/...) was the right direction, and could resolve the problems with the previous attempt with two changes:

  1. Tag a github.com/spf13/cobra release after adding the sub go.mod so github.com/spf13/cobra@latest resolves to a version that does not provide the github.com/spf13/cobra/cobra package.
  2. Update github.com/spf13/cobra/cobra to refer to the tagged github.com/spf13/cobra release created in step 1 so that it works with go get and go install

Testing

To test this approach, I:

  1. cloned this repo to github.com/liggitt/cobra, and created tags at various points in cobra's history with the import paths renamed (v1.0.0, v1.1.3, and v1.3.0)
  2. created a go.mod file at github.com/liggitt/cobra/cobra, committed and tagged as github.com/liggitt/cobra v1.5.0 - liggitt@0c686b5
  3. updated the go.mod file at github.com/liggitt/cobra/cobra to refer to github.com/liggitt/cobra@v1.5.0, committed and tagged github.com/liggitt/cobra/cobra cobra/v1.5.0 - liggitt@458f3c5

Now, all of the following still work with no complaints about ambiguous import paths:

go get:

go get github.com/liggitt/cobra
go get github.com/liggitt/cobra@v1.3.0
go get github.com/liggitt/cobra@v1.5.0
go get github.com/liggitt/cobra@latest
go get -u github.com/liggitt/cobra
go get -u github.com/liggitt/cobra@v1.3.0
go get -u github.com/liggitt/cobra@latest

go install:

go install github.com/liggitt/cobra/cobra@v1.3.0
go install github.com/liggitt/cobra/cobra@v1.5.0
go install github.com/liggitt/cobra/cobra@latest

Impact on library consumers

To see what the impact would be on downstream consumers of this library, I took Kubernetes' use as an example (test commits visible in https://github.com/liggitt/kubernetes/commits/cobra130):

  1. made copies of Kubernetes dependencies that refer to spf13/cobra@{v1.0.0,v1.1.3,v1.3.0}, and adjusted Kubernetes and the dependencies to use liggitt/cobra at the same versions
  2. updated Kubernetes to use liggitt/cobra@v1.5.0
  3. saw a significant number of transitive dependencies drop out of our dependency graph:
    • cloud.google.com/go/firestore
    • github.com/DataDog/datadog-go
    • github.com/armon/go-metrics
    • github.com/armon/go-radix
    • github.com/bgentry/speakeasy
    • github.com/circonus-labs/circonus-gometrics
    • github.com/circonus-labs/circonusllhist
    • github.com/fatih/color
    • github.com/hashicorp/consul/api
    • github.com/hashicorp/consul/sdk
    • github.com/hashicorp/errwrap
    • github.com/hashicorp/go-cleanhttp
    • github.com/hashicorp/go-hclog
    • github.com/hashicorp/go-immutable-radix
    • github.com/hashicorp/go-msgpack
    • github.com/hashicorp/go-multierror
    • github.com/hashicorp/go-retryablehttp
    • github.com/hashicorp/go-rootcerts
    • github.com/hashicorp/go-sockaddr
    • github.com/hashicorp/go-syslog
    • github.com/hashicorp/go-uuid
    • github.com/hashicorp/golang-lru
    • github.com/hashicorp/hcl
    • github.com/hashicorp/logutils
    • github.com/hashicorp/mdns
    • github.com/hashicorp/memberlist
    • github.com/hashicorp/serf
    • github.com/magiconair/properties
    • github.com/mattn/go-colorable
    • github.com/mattn/go-isatty
    • github.com/miekg/dns
    • github.com/mitchellh/cli
    • github.com/mitchellh/go-homedir
    • github.com/mitchellh/go-testing-interface
    • github.com/pascaldekloe/goe
    • github.com/pelletier/go-toml
    • github.com/posener/complete
    • github.com/ryanuber/columnize
    • github.com/sagikazarmark/crypt
    • github.com/sean-/seed
    • github.com/spf13/cast
    • github.com/spf13/jwalterweatherman
    • github.com/spf13/viper
    • github.com/subosito/gotenv
    • github.com/tv42/httpunix
    • gopkg.in/ini.v1

Impact on library consumers of github.com/spf13/cobra/cobra/...

There don't appear to be very many consumers of these packages (which is not surprising, since their purpose is to support the cobra command line):

Any consumers using these packages beyond v1.3.0 would need to depend on the github.com/spf13/cobra/cobra module instead.


Impact on development

Changes that span the two modules would become more difficult to make, and could not be committed/pushed in a single PR. This is because the two modules are effectively behaving like two distinct modules that happen to live in the same repo, and a release of the library module would be required before the command module could start relying on the changes in it via a publicly referenced version.


Impact on release mechanics

Currently, to release github.com/spf13/cobra:

  1. create and push a v1.x.y git tag

With multiple modules, effectively, two releases would be required (one for the library and one for the command), which would require two tags and a go.mod change:

  1. create and push a v1.x.y git tag
  2. update the github.com/spf13/cobra/cobra/go.mod file to reference that version of the github.com/spf13/cobra library, go mod tidy, commit and push
  3. create and push a cobra/v1.x.y git tag
@jpmcb
Copy link
Collaborator

jpmcb commented Feb 8, 2022

Thanks for the in depth research on this!

Pinning since I think this issue is the most fresh in regards to how we pull in viper and it's deep dependency chain.

Let's also get @marckhouzam and @umarcor eyes on this 👀

@jpmcb jpmcb pinned this issue Feb 8, 2022
@jpmcb
Copy link
Collaborator

jpmcb commented Feb 8, 2022

FYI @spf13 - I think we will plan to move forward with this since we are getting more and more requests from kubernetes/kubernetes, helm, vmware-tanzu, etc to decouple the dependencies.

We've also seen the rise of a prominent fork which is the same as cobra but removes the interlinking of the cobra CLI and the cobra library. So, I'd also like to invite @muesli to provide their feedback and thoughts on this proposal.

@jpmcb jpmcb added this to the Next milestone Feb 8, 2022
@jpmcb
Copy link
Collaborator

jpmcb commented Feb 9, 2022

Proposal review:

It would greatly help downstream consumers if this library could be consumed without picking up the viper dependencies.

100% agree. This is a long standing problem and something that has been challenging for downstream consumers and maintainers to keep ontop of. Further, it only exacerbates a challenging secure supply chain issue: we shouldn't be bringing unnecessary dependencies into kubernetes/kubernetes, helm, tanzu, etc.

History

Also note that at the time we attempted this, cobra did not have a release cycle and it was expected that users would pull off of the main branch. If I remember correctly, this was even before go mod v2. I think that now, we are in a better place to tag the appropriate release, and get the necessary bits out in the wild where they can be consumed.

I agree with spf13 that we should avoid solutions that disrupt current consumers of the github.com/spf13/cobra import path.

Yes, I 100% agree. There are far too many large projects downstream that rely on the library import path and we do not have the open source bandwidth to advocate those projects change their import path.

There don't appear to be very many consumers of these packages

There shouldn't be since it's primary purpose is to bootstrap a new cobra program via it's CLI. I'd say anyone that is using it should transition to using the library directly.

the two modules are effectively behaving like two distinct modules that happen to live in the same repo
...
With multiple modules, effectively, two releases would be required

⚠️ This is my only concern. This effectively makes spf13/cobra a library distribution and a consumer of it's own library. I agree this would make development work more challenging and almost creates a circular dependency. Part of me wonders if this is a better chance to remove the cobra CLI from this project and move it to it's own repo. That way, the upstream, downstream model makes much more sense. But if that isn't what we want to do, I don't think we should block on that.

The release cadences are already difficult (given we need an injection of engineering and maintainer resources). So If at all possible, it'd be great if this wasn't made more difficult.

My only suggestion is that we consider moving the cobra CLI to it's own repository. If @spf13 doesn't have bandwidth to do that, I'd be happy to provide a repo and also maintain it along side this library. And if we don't want to remove it, I think your proposal is extremely solid and would work in the long run.

@liggitt
Copy link
Contributor Author

liggitt commented Feb 9, 2022

This effectively makes spf13/cobra a library distribution and a consumer of it's own library.

it would be a multi-module repo (https://go.dev/doc/modules/managing-source#multiple-module-source), where each module gets its own lifecycle/tags/etc, and only refers to the other modules in the same repo via committed/published tags

I agree this would make development work more challenging and almost creates a circular dependency.

Fortunately, the dependency is still directed, not circular (command depends on library), but yeah, it could make development across the two modules more difficult (though no different from multi-repo development, if a release of the library is required before library changes are picked up and used by the command)

Part of me wonders if this is a better chance to remove the cobra CLI from this project and move it to it's own repo. That way, the upstream, downstream model makes much more sense. But if that isn't what we want to do, I don't think we should block on that.

The release cadences are already difficult (given we need an injection of engineering and maintainer resources). So If at all possible, it'd be great if this wasn't made more difficult.

My only suggestion is that we consider moving the cobra CLI to it's own repository.

Note that the "two release" aspect isn't required to happen in lockstep, only when you want the command module to pick up and start making use of changes added to the library module

The only real pros I can think of for keeping the command in the same repo are:

  • preserving the ~4 importers of the go path
  • preserving all the places people have scripted go get (or install) github.com/spf13/cobra/cobra to install the command

That second one (the install command) might be significant… I suspect you'd get a lot of reports of breakage if the current install method stopped working

@spf13
Copy link
Owner

spf13 commented Feb 9, 2022

I fully support moving to having viper not imported by default.

Honestly that decision was made very VERY early in the lifecycle of Go and I don't think any of us understood how dependencies would have played out. I also had no idea how popular this little library of mine would become.

FWIW, The viper folks are working on a version that dramatically reduces it's dependencies as well. This should minimize, but not eliminate the problem that we're addressing here. cc: @sagikazarmark for his input and visibility.

For separating the CLI from the library, I'm not sure what the right answer is but have a few requirements.

  1. It should be as easy to work with as possible for the Cobra maintainers.
  2. It should not introduce any additional dependencies for users (or any additional complications)
  3. Let's try to not change things as much as possible.

My guess is that the option that addresses these the requirements the best is to move it to it's own repo. Very little coordination happens between the CLI and the library because the CLI is very simple. Not having to worry about multiple modules in a repo is simpler. The only disadvantage I see is that all documentation around Cobra CLI will point to the wrong install string. This is unfortunate, but I think we can message this okay. I'm much more concerned about breaking dependencies that are automated things vs something that a human is manually doing. We can inform the human of a new installation command. If we go down this route we should put it at github.com/spf13/cobra-cli (or similar) so it's still discoverable when people look for spf13/cobra.

Am I missing anything or not thinking about it correctly?

@liggitt
Copy link
Contributor Author

liggitt commented Feb 9, 2022

From a library consumer and cobra maintainer perspective, moving the CLI to a separate repo is certainly easy to reason about, accomplishes the dependency reduction goals for the library, and is simpler to maintain.

If we're confident all (or the majority) of installation invocations are done by humans we can inform, and not scripted in automation we'll break, that sounds reasonable. I'm not familiar enough with use of the CLI side of this repo to know if that's the case.

If we go down this route we should put it at github.com/spf13/cobra-cli (or similar) so it's still discoverable when people look for spf13/cobra.

I assume we'd still want something that produced a cobra binary. Does that require the last path segment to be "cobra"?

@muesli
Copy link
Contributor

muesli commented Feb 9, 2022

My guess is that the option that addresses these the requirements the best is to move it to it's own repo.

I believe this is the right decision here. Introducing a sub-go.mod is typically causing more issues, not only on a technical level, but also with regards to awareness and obviousness. With the CLI living in a separate repository these concerns would be eliminated.

Very little coordination happens between the CLI and the library because the CLI is very simple. Not having to worry about multiple modules in a repo is simpler. The only disadvantage I see is that all documentation around Cobra CLI will point to the wrong install string. This is unfortunate, but I think we can message this okay. I'm much more concerned about breaking dependencies that are automated things vs something that a human is manually doing. We can inform the human of a new installation command. If we go down this route we should put it at github.com/spf13/cobra-cli (or similar) so it's still discoverable when people look for spf13/cobra.

I completely agree with this 👍

I'd also like to point out that in my (admittedly limited and personal) experience only a fraction of Cobra's users are actually using the CLI tool. It's definitely nice to have when experimenting with Cobra in the beginning, but once you figured out how this library works most everyone I work with gets by without using the CLI. If that's not just my "personal anecdote" it's probably another good indicator the CLI should be moved to a separate repository.

@caarlos0
Copy link
Contributor

caarlos0 commented Feb 9, 2022

Another good candidate to be a separated module: the docs and man page generators.

IMHO, ideally they should be interfaces the user can implement themselves, or import packages that does it for them. This way we could drop even more transitive dependencies, and also allow for more customization.

@sagikazarmark
Copy link
Contributor

sagikazarmark commented Feb 9, 2022

Thanks for pinging me @spf13 !

I think I agree with most of what's been said before. I only have a couple additional thoughts:

  • The Cobra-Viper integration is regularly misunderstood by consumers and they often come to the Viper repo opening issues that can't be helped, so personally I fully support removing Viper as a direct dependency.
  • It's been a long road, but finally we have a direction at Viper: the plan is to reduce the dependencies by moving out some of the components to separate packages. I agree with @spf13 that this itself wouldn't solve the dependency problem for cobra though.
  • Those separate packages I mentioned will be under a go-viper/viper-go organization on GitHub (at least that's the current plan). If cobra ends up being split up as well, we might want to consider moving things under a single, CLI focused organization (even if they won't directly depend on each other)

I'd be happy to work with you to improve the situation (Cobra and Viper belong roughly to the same ecosystem after all).

@liggitt
Copy link
Contributor Author

liggitt commented Feb 9, 2022

If we're confident all (or the majority) of installation invocations are done by humans we can inform, and not scripted in automation we'll break, that sounds reasonable. I'm not familiar enough with use of the CLI side of this repo to know if that's the case.

doing a quick sweep of public references in https://grep.app/search?q=github.com/spf13/cobra/cobra

That's a small enough number we could plausibly open PRs to fix the references to point to the new repo containing the command. I'd be in favor of this order of operations:

  1. Create new repo, containing a copy of the current github.com/spf13/cobra/cobra/... code (I like @spf13's suggestion of cobra-cli... an install command of go install github.com/spf13/cobra-cli/cobra seems coherent and still produces a cobra binary), and tag a release (probably v1.3.0 to match the current version in this repo)
  2. Open PRs to the public programmatic references (go imports and scripted installs)
  3. Open issues or propose PRs updating the public documentation references found in other repos (including the example install command in this repo)
  4. Remove github.com/spf13/cobra/cobra/... packages and tag a new version of github.com/spf13/cobra

@jpmcb
Copy link
Collaborator

jpmcb commented Feb 9, 2022

I'd also like to point out that in my (admittedly limited and personal) experience only a fraction of Cobra's users are actually using the CLI tool.

From supporting this project over the last few years, this has been my experience too. Alot of users get started with the CLI, but they quickly move on to just using the library.

Those separate packages I mentioned will be under a go-viper/viper-go organization on GitHub (at least that's the current plan). If cobra ends up being split up as well, we might want to consider moving things under a single, CLI focused organization (even if they won't directly depend on each other)

I had thought of doing something similar, moving cobra into a more easily administrated github organization, but that breaks the import path. How does viper plan to handle that for it's users?


Edit

I went ahead and grabbed the github.com/go-cobra org just in case we want this (now or sometime into the future)

@umarcor
Copy link
Contributor

umarcor commented Feb 9, 2022

IMHO, the cobra library itself should be isolated from other optional and less used components. Unfortunately, there is no way to achieve it without introducing breaking changes, because those sources are in the root of the current repository. I believe there are two decisions to make:

  • Keep cobra as a monorepo.
  • Split cobra in multiple repos.
    • (bis) Put those multiple repos in a namespace other than spf13's.

In order to avoid breaking changes, the only solution is to keep the monorepo and increase the maintenance burden.

My preference is to move cobra to the snakes org, AND move the lib to a subdir. Both at the same time. Probably consider applying other breaking changes (if any) at the same time.

@jpmcb
Copy link
Collaborator

jpmcb commented Feb 9, 2022

applying other breaking changes (if any) at the same time.

This is an anti-goal of this operation. We should not induce more user pain than will already be felt by possibly changing the import path, removing dependencies, or introducing a different way to get the cobra CLI.

@spf13
Copy link
Owner

spf13 commented Feb 9, 2022

I really feel strongly that the import strings for both Cobra and Viper shouldn't change. They have way too large adoption to justify this change. Cobra is imported over 51k times. Viper over 27k times. This is an overwhelmingly high number of users to consider making a breaking change. github.com/spf13/cobra and github.com/spf13/viper need to stay where they are.

I'm supportive of having extraneous components moved to different repos as it will simplify things for our maintainers and likely our users as well. If we limit this to things that aren't currently directly imported then we can improve things for everyone without breaking anyone. This is the ideal direction to take.

I concur with many of you. Cobra-cli isn't very widely used and the vast majority of usage is when you are starting a new application. It's really not very useful once the application is bootstrapped. I don't think it would even be problematic to rename it to cobra-cli. If anything, it might actually make some things clearer in the documentation (once revised).

I think we're all in agreement that the implicit dependency on viper should be removed (the topic of this thread).
It seems like were all also in agreement that we can decouple the cobra-cli.

Both of these are big steps in the right direction. It might be worth moving forward with these two steps and keep thinking about the best way to approach further steps.

My preference for the cli is (as stated earlier) github.com/spf13/cobra-cli and give access to all the same people as cobra. I'm happy to set this up. I think that this is the simplest path forward for users and it would be the easiest to discover.

@liggitt
Copy link
Contributor Author

liggitt commented Feb 9, 2022

My preference for the cli is (as stated earlier) github.com/spf13/cobra-cli and give access to all the same people as cobra. I'm happy to set this up. I think that this is the simplest path forward for users and it would be the easiest to discover.

+1

I think keeping the extracted command in the same org will make it easier to convince consumers to accept updates to docs/scripts to point to the new location. As a data point, if someone came to Kubernetes with a PR trying to update a dependency to pull it from a different org, I'd need to vet the new org, make sure it was official, understand which was more up-to-date / canonical, etc. It would definitely be more work and friction than:

- github.com/spf13/cobra/cobra
+ github.com/spf13/cobra-cli/cobra

@sagikazarmark
Copy link
Contributor

sagikazarmark commented Feb 9, 2022

I had thought of doing something similar, moving cobra into a more easily administrated github organization, but that breaks the import path. How does viper plan to handle that for it's users?

@jpmcb The core library will stay where it is. Extracted components will be moved under the new organization.

As @spf13 mentioned, keeping things backwards compatible as much as possible is an important goal.

@umarcor
Copy link
Contributor

umarcor commented Feb 9, 2022

We should not induce more user pain than will already be felt by possibly changing the import path, removing dependencies, or introducing a different way to get the cobra CLI.

@jpmcb, I believe it's better to have 2-3 breaking changes once and explain them clear enough, rather than having them go through pain for 1-2y. Anyway, it seems the majority decided to move the subdirs away and preserve the root.

keeping the extracted command in the same org

@liggitt, note that 'spf13' is not an organisation, but a user. That is probably irrelevant from golang's perspective, but is meaningful from a management point of view.

My preference for the cli is (as stated earlier) github.com/spf13/cobra-cli

@spf13, will you create github.com/spf13/cobra-docs as well?

@jpmcb
Copy link
Collaborator

jpmcb commented Feb 9, 2022

My preference for the cli is (as stated earlier) github.com/spf13/cobra-cli and give access to all the same people as cobra. I'm happy to set this up. I think that this is the simplest path forward for users and it would be the easiest to discover.

+1 this sounds good to me!

@spf13
Copy link
Owner

spf13 commented Feb 10, 2022

ok. I've gone ahead and created the cobra-cli repo and used git subtree split to break out the entire /cobra subdirectory, thus retaining all the history in the current project.

I've given access to all existing contributors and added @liggitt too.

This should give us a good working foundation to make the proposed changes. We still need to add things like a license, update the readme and then update the old repo and remove the directory there.

@umarcor I'm a bit more concerned about pulling the docs out as unlike the generator which really has barely changed, the docs need to keep in step with the main codebase. A very convenient way to do that is keep them in the same repo. The website (cobra.dev) is already in it's own repo.

I'd like a few others to weigh in before making this one.

@umarcor
Copy link
Contributor

umarcor commented Feb 10, 2022

@spf13 I meant the ./doc module that @caarlos0 mentioned above. I agree that the documentation is better kept with the main codebase (here, in cobra-cli, etc.).

@liggitt
Copy link
Contributor Author

liggitt commented Feb 10, 2022

I've gone ahead and created the cobra-cli repo and used git subtree split to break out the entire /cobra subdirectory, thus retaining all the history in the current project.

I'm happy to open an initial PR to rename import paths in that repo, copy over the license and create a starting go.mod file, etc - spf13/cobra-cli#1

Before we merge anything to that repo, I wanted to make sure we were set with the leaf package containing the new cli being .../cobra-cli and not .../cobra-cli/cobra. As it stands now, the repo produces a cobra-cli binary. Keeping the binary name cobra would limit changes for consumers to the install command, and leave all invocations of the binary and other docs untouched.

@spf13
Copy link
Owner

spf13 commented Feb 10, 2022

@jpmcb
Copy link
Collaborator

jpmcb commented Feb 10, 2022

I'm in favor of naming it cobra-cli.

I agree; having a library named cobra and a CLI tool named cobra is confusing. I think if we document this change appropriately, it should be ok and new users bootstrapping with the CLI tool should discover it appropriately.

@marckhouzam
Copy link
Collaborator

marckhouzam commented Mar 4, 2022

opened PRs to switch the 4 projects with public go imports of github.com/spf13/cobra/cobra to cobra-cli

opened PRs to switch the public projects with scripted install / go get references to install cobra-cli or go get github.com/spf13/cobra (if they were setting up the library)

Thank you so much @liggitt for doing this!

With this done, are there any other blockers to remove the cobra generator from this repo (#1604)?

@liggitt
Copy link
Contributor Author

liggitt commented Mar 4, 2022

With this done, are there any other blockers to remove the cobra generator from this repo (#1604)?

I was hoping to get at least the updates to programmatic and scripted references merged, but if there hasn't been activity on those by next week, proceeding with #1604 seems reasonable to me.

@jpmcb
Copy link
Collaborator

jpmcb commented Mar 5, 2022

Most of the references (at least in the go mod files) look to not be tracking the master branch, but a previous release. So I think we could merge #1604 soon in anticipation of a release

@liggitt
Copy link
Contributor Author

liggitt commented Mar 9, 2022

Most of the references (at least in the go mod files) look to not be tracking the master branch, but a previous release. So I think we could merge #1604 soon in anticipation of a release

I agree. I'm happy to see #1604 proceed at this point.

@marckhouzam
Copy link
Collaborator

marckhouzam commented Mar 10, 2022

I was wondering about the next release version. Does removing the Cobra generator require us to bump the major version?

We are not actually breaking anyone that integrates the Cobra library, and bumping the major version sends a signal that people have work to do to move to the new release (when it is not actually the case). This may unnecessarily slow down adoption.

I would personally prefer going for a v1.4.0 release.

What do others think?

@liggitt
Copy link
Contributor Author

liggitt commented Mar 10, 2022

v1.4.0 is what I anticipated, not a v2 that changes the import path

from #1597 (comment), it sounds like @spf13 expected the same:

I really feel strongly that the import strings for both Cobra and Viper shouldn't change.

@marckhouzam
Copy link
Collaborator

marckhouzam commented Mar 10, 2022

v1.4.0 is what I anticipated, not a v2 that changes the import path

from #1597 (comment), it sounds like @spf13 expected the same:

I really feel strongly that the import strings for both Cobra and Viper shouldn't change.

Oh right! Moving to v2 would change the import path. That is a huge deal.

So v1.4.0 is great.

@umarcor
Copy link
Contributor

umarcor commented Mar 10, 2022

@marckhouzam @liggitt maybe you can create a 1.4.0 milestone and mark the PRs (#1565 (comment)) accordingly, as done for 1.3.0.

@marckhouzam
Copy link
Collaborator

marckhouzam commented Mar 10, 2022

Do we want a quick release for the removal of the Viper dependency, or do we want to lump it in the original "Winter" release?

@liggitt
Copy link
Contributor Author

liggitt commented Mar 10, 2022

if the winter 2022 release was going to be 1.4.0, lumping it in and going ahead and tagging makes sense to me... we're only 11 days from spring 2022 anyway

@jpmcb
Copy link
Collaborator

jpmcb commented Mar 10, 2022

I think we should do a v1.4.0 release now that the viper deps are out and close out #1565, focusing on #1626 going forward

@marckhouzam
Copy link
Collaborator

marckhouzam commented Mar 10, 2022

I think we should do a v1.4.0 release now that the viper deps are out and close out #1565, focusing on #1626 going forward

I see that everything that was originally left in the Winter release has been moved to the Spring release 😄
So the Winter release seems ready and will pretty much only contain the Viper dep removal.

@jpmcb
Copy link
Collaborator

jpmcb commented Mar 10, 2022

Sweet! Drafting v1.4.0 now 👀

@marckhouzam
Copy link
Collaborator

marckhouzam commented Mar 10, 2022

@marckhouzam @liggitt maybe you can create a 1.4.0 milestone and mark the PRs (#1565 (comment)) accordingly, as done for 1.3.0.

I will do this.

@jpmcb
Copy link
Collaborator

jpmcb commented Mar 10, 2022

https://github.com/spf13/cobra/releases/tag/v1.4.0

Great work everyone!!!! 🚀

@jpmcb jpmcb closed this as completed Mar 10, 2022
gcf-merge-on-green bot pushed a commit to googleapis/gapic-showcase that referenced this issue Mar 10, 2022
[![WhiteSource Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [github.com/spf13/cobra](https://togithub.com/spf13/cobra) | require | minor | `v1.3.0` -> `v1.4.0` |

---

### Release Notes

<details>
<summary>spf13/cobra</summary>

### [`v1.4.0`](https://togithub.com/spf13/cobra/releases/v1.4.0)

[Compare Source](https://togithub.com/spf13/cobra/compare/v1.3.0...v1.4.0)

### Winter 2022 Release ❄️

Another season, another release!

#### Goodbye viper! 🐍 🚀

The core Cobra library no longer requires Viper and all of it's indirect dependencies. This means that Cobra's dependency tree has been drastically thinned! The Viper dependency was included because of the the `cobra` CLI generation tool. [This tool has migrated to `spf13/cobra-cli`](https://togithub.com/spf13/cobra-cli/releases/tag/v1.3.0).

It's *pretty unlikely* you were importing and using **the bootstrapping CLI tool** as part of your application (after all, it's just a tool to get going with core `cobra`).

But if you were, replace occurrences of

    "github.com/spf13/cobra/cobra"

with

    "github.com/spf13/cobra-cli"

And in your `go.mod`, you'll want to also include this dependency:

    github.com/spf13/cobra-cli v1.3.0

Again, the maintainers *do not anticipate* this being a breaking change to users of the core `cobra` library, so minimal work should be required for users to integrate with this new release. Moreover, this means the dependency tree for your application using Cobra should no longer require dependencies that were inherited from Viper. Huzzah! 🥳

If you'd like to read more

-   issue: [spf13/cobra#1597
-   PR: [spf13/cobra#1604

#### Documentation 📝

-   Update Go Doc link and badge in README: [spf13/cobra#1593
-   Fix to install command, now targets `@latest`: [spf13/cobra#1576
-   Added MAINTAINERS file: [spf13/cobra#1545

#### Other 💭

-   Bumped license year to 2022 in golden files: [spf13/cobra#1575
-   Added Pixie to projects: [spf13/cobra#1581
-   Updated labeler for new labeling scheme: [spf13/cobra#1613 & syntax fix: [spf13/cobra#1624

Shoutout to our awesome contributors helping to make this cobra release possible!!
[@&#8203;spf13](https://togithub.com/spf13) [@&#8203;marckhouzam](https://togithub.com/marckhouzam) [@&#8203;johnSchnake](https://togithub.com/johnSchnake) [@&#8203;jpmcb](https://togithub.com/jpmcb) [@&#8203;liggitt](https://togithub.com/liggitt) [@&#8203;umarcor](https://togithub.com/umarcor) [@&#8203;hiljusti](https://togithub.com/hiljusti) [@&#8203;marians](https://togithub.com/marians) [@&#8203;shyim](https://togithub.com/shyim) [@&#8203;htroisi](https://togithub.com/htroisi)

</details>

---

### Configuration

📅 **Schedule**: At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

 **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by [WhiteSource Renovate](https://renovate.whitesourcesoftware.com). View repository job log [here](https://app.renovatebot.com/dashboard#github/googleapis/gapic-showcase).
@umarcor
Copy link
Contributor

umarcor commented Mar 10, 2022

@marckhouzam this issue is milestoned as "Next"; maybe change it to 1.4.0.

@marckhouzam marckhouzam modified the milestones: Next, 1.4.0 Mar 10, 2022
aviator-app bot pushed a commit to airplanedev/cli that referenced this issue Mar 17, 2022
[![WhiteSource Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [github.com/golang-jwt/jwt/v4](https://togithub.com/golang-jwt/jwt) | require | minor | `v4.3.0` -> `v4.4.0` |
| [github.com/google/uuid](https://togithub.com/google/uuid) | require | minor | `v1.2.0` -> `v1.3.0` |
| [github.com/spf13/cobra](https://togithub.com/spf13/cobra) | require | minor | `v1.3.0` -> `v1.4.0` |
| [github.com/stretchr/testify](https://togithub.com/stretchr/testify) | require | patch | `v1.7.0` -> `v1.7.1` |

---

### Release Notes

<details>
<summary>golang-jwt/jwt</summary>

### [`v4.4.0`](https://togithub.com/golang-jwt/jwt/releases/v4.4.0)

[Compare Source](https://togithub.com/golang-jwt/jwt/compare/v4.3.0...v4.4.0)

#### What's Changed

-   fix: expired token error message by [@&#8203;ydylla](https://togithub.com/ydylla) in [golang-jwt/jwt#165
-   feat: port clockskew support by [@&#8203;ksegun](https://togithub.com/ksegun) in [golang-jwt/jwt#139

#### New Contributors

-   [@&#8203;ydylla](https://togithub.com/ydylla) made their first contribution in [golang-jwt/jwt#165
-   [@&#8203;ksegun](https://togithub.com/ksegun) made their first contribution in [golang-jwt/jwt#139

**Full Changelog**: golang-jwt/jwt@v4.3.0...v4.4.0

</details>

<details>
<summary>google/uuid</summary>

### [`v1.3.0`](https://togithub.com/google/uuid/releases/v1.3.0)

[Compare Source](https://togithub.com/google/uuid/compare/v1.2.0...v1.3.0)

From Andrey Pechkurov:

Adds an optional randomness pool mode for Random (Version 4) UUID generation. The pool contains random bytes read from the random number generator on demand in batches. Enabling the pool may improve the UUID generation throughput significantly.

Since the pool is stored on the Go heap, this feature may be a bad fit for security sensitive applications. That's why it's implemented as an opt-in feature.

From Samuel Roth:

Added support for NullUUID

A NullUUID can be marked not valid (i.e., null) for use with JSON and the database/sql/driver.Scanner interfaces.

</details>

<details>
<summary>spf13/cobra</summary>

### [`v1.4.0`](https://togithub.com/spf13/cobra/releases/v1.4.0)

[Compare Source](https://togithub.com/spf13/cobra/compare/v1.3.0...v1.4.0)

### Winter 2022 Release ❄️

Another season, another release!

#### Goodbye viper! 🐍 🚀

The core Cobra library no longer requires Viper and all of its indirect dependencies. This means that Cobra's dependency tree has been drastically thinned! The Viper dependency was included because of the `cobra` CLI generation tool. [This tool has migrated to `spf13/cobra-cli`](https://togithub.com/spf13/cobra-cli/releases/tag/v1.3.0).

It's *pretty unlikely* you were importing and using **the bootstrapping CLI tool** as part of your application (after all, it's just a tool to get going with core `cobra`).

But if you were, replace occurrences of

    "github.com/spf13/cobra/cobra"

with

    "github.com/spf13/cobra-cli"

And in your `go.mod`, you'll want to also include this dependency:

    github.com/spf13/cobra-cli v1.3.0

Again, the maintainers *do not anticipate* this being a breaking change to users of the core `cobra` library, so minimal work should be required for users to integrate with this new release. Moreover, this means the dependency tree for your application using Cobra should no longer require dependencies that were inherited from Viper. Huzzah! 🥳

If you'd like to read more

-   issue: [spf13/cobra#1597
-   PR: [spf13/cobra#1604

#### Documentation 📝

-   Update Go Doc link and badge in README: [spf13/cobra#1593
-   Fix to install command, now targets `@latest`: [spf13/cobra#1576
-   Added MAINTAINERS file: [spf13/cobra#1545

#### Other 💭

-   Bumped license year to 2022 in golden files: [spf13/cobra#1575
-   Added Pixie to projects: [spf13/cobra#1581
-   Updated labeler for new labeling scheme: [spf13/cobra#1613 & syntax fix: [spf13/cobra#1624

Shoutout to our awesome contributors helping to make this cobra release possible!!
[@&#8203;spf13](https://togithub.com/spf13) [@&#8203;marckhouzam](https://togithub.com/marckhouzam) [@&#8203;johnSchnake](https://togithub.com/johnSchnake) [@&#8203;jpmcb](https://togithub.com/jpmcb) [@&#8203;liggitt](https://togithub.com/liggitt) [@&#8203;umarcor](https://togithub.com/umarcor) [@&#8203;hiljusti](https://togithub.com/hiljusti) [@&#8203;marians](https://togithub.com/marians) [@&#8203;shyim](https://togithub.com/shyim) [@&#8203;htroisi](https://togithub.com/htroisi)

</details>

<details>
<summary>stretchr/testify</summary>

### [`v1.7.1`](https://togithub.com/stretchr/testify/compare/v1.7.0...v1.7.1)

[Compare Source](https://togithub.com/stretchr/testify/compare/v1.7.0...v1.7.1)

</details>

---

### Configuration

📅 **Schedule**: "before 5am on Thursday" in timezone America/New_York.

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

 **Rebasing**: Renovate will not automatically rebase this PR, because other commits have been found.

👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox.
gcf-merge-on-green bot pushed a commit to GoogleCloudPlatform/alloydb-auth-proxy that referenced this issue May 18, 2022
[![WhiteSource Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [github.com/spf13/cobra](https://togithub.com/spf13/cobra) | require | minor | `v1.2.1` -> `v1.4.0` |

---

### Release Notes

<details>
<summary>spf13/cobra</summary>

### [`v1.4.0`](https://togithub.com/spf13/cobra/releases/v1.4.0)

[Compare Source](https://togithub.com/spf13/cobra/compare/v1.3.0...v1.4.0)

### Winter 2022 Release ❄️

Another season, another release!

#### Goodbye viper! 🐍 🚀

The core Cobra library no longer requires Viper and all of its indirect dependencies. This means that Cobra's dependency tree has been drastically thinned! The Viper dependency was included because of the `cobra` CLI generation tool. [This tool has migrated to `spf13/cobra-cli`](https://togithub.com/spf13/cobra-cli/releases/tag/v1.3.0).

It's *pretty unlikely* you were importing and using **the bootstrapping CLI tool** as part of your application (after all, it's just a tool to get going with core `cobra`).

But if you were, replace occurrences of

    "github.com/spf13/cobra/cobra"

with

    "github.com/spf13/cobra-cli"

And in your `go.mod`, you'll want to also include this dependency:

    github.com/spf13/cobra-cli v1.3.0

Again, the maintainers *do not anticipate* this being a breaking change to users of the core `cobra` library, so minimal work should be required for users to integrate with this new release. Moreover, this means the dependency tree for your application using Cobra should no longer require dependencies that were inherited from Viper. Huzzah! 🥳

If you'd like to read more

-   issue: [spf13/cobra#1597
-   PR: [spf13/cobra#1604

#### Documentation 📝

-   Update Go Doc link and badge in README: [spf13/cobra#1593
-   Fix to install command, now targets `@latest`: [spf13/cobra#1576
-   Added MAINTAINERS file: [spf13/cobra#1545

#### Other 💭

-   Bumped license year to 2022 in golden files: [spf13/cobra#1575
-   Added Pixie to projects: [spf13/cobra#1581
-   Updated labeler for new labeling scheme: [spf13/cobra#1613 & syntax fix: [spf13/cobra#1624

Shoutout to our awesome contributors helping to make this cobra release possible!!
[@&#8203;spf13](https://togithub.com/spf13) [@&#8203;marckhouzam](https://togithub.com/marckhouzam) [@&#8203;johnSchnake](https://togithub.com/johnSchnake) [@&#8203;jpmcb](https://togithub.com/jpmcb) [@&#8203;liggitt](https://togithub.com/liggitt) [@&#8203;umarcor](https://togithub.com/umarcor) [@&#8203;hiljusti](https://togithub.com/hiljusti) [@&#8203;marians](https://togithub.com/marians) [@&#8203;shyim](https://togithub.com/shyim) [@&#8203;htroisi](https://togithub.com/htroisi)

### [`v1.3.0`](https://togithub.com/spf13/cobra/releases/v1.3.0)

[Compare Source](https://togithub.com/spf13/cobra/compare/v1.2.1...v1.3.0)

### v1.3.0 - The Fall 2021 release 🍁

#### Completion fixes & enhancements 💇🏼

In `v1.2.0`, we introduced a new model for completions. Thanks to everyone for trying it, giving feedback, and providing numerous fixes! Continue to work with the new model as the old one (as noted in code comments) will be deprecated in a coming release.

-   `DisableFlagParsing` now triggers custom completions for flag names [#&#8203;1161](https://togithub.com/spf13/cobra/issues/1161)
-   Fixed unbound variables in bash completions causing edge case errors [#&#8203;1321](https://togithub.com/spf13/cobra/issues/1321)
-   `help` completion formatting improvements & fixes [#&#8203;1444](https://togithub.com/spf13/cobra/issues/1444)
-   All completions now follow the `help` example: short desc are now capitalized and removes extra spacing from long description [#&#8203;1455](https://togithub.com/spf13/cobra/issues/1455)
-   Typo fixes in bash & zsh completions [#&#8203;1459](https://togithub.com/spf13/cobra/issues/1459)
-   Fixed mixed tab/spaces indentation in completion scripts. Now just 4 spaces [#&#8203;1473](https://togithub.com/spf13/cobra/issues/1473)
-   Support for different bash completion options. Bash completions v2 supports descriptions and requires descriptions to be removed for `menu-complete`, `menu-complete-backward` and `insert-completions`. These descriptions are now purposefully removed in support of this model. [#&#8203;1509](https://togithub.com/spf13/cobra/issues/1509)
-   Fix for invalid shell completions when using `~/.cobra.yaml`. Log message `Using config file: ~/.cobra.yaml` now printed to stderr [#&#8203;1510](https://togithub.com/spf13/cobra/issues/1510)
-   Removes unnecessary trailing spaces from completion command descriptions [#&#8203;1520](https://togithub.com/spf13/cobra/issues/1520)
-   Option to hide default `completion` command [#&#8203;1541](https://togithub.com/spf13/cobra/issues/1541)
-   Remove `__complete` command for programs without subcommands [#&#8203;1563](https://togithub.com/spf13/cobra/issues/1563)

#### Generator changes ⚙️

Thanks to [@&#8203;spf13](https://togithub.com/spf13) for providing a number of changes to the Cobra generator tool, streamlining it for new users!

-   The Cobra generator now *won't* automatically include Viper and cleans up a number of unused imports when not using Viper.
-   The Cobra generator's default license is now `none`
-   The Cobra generator now works with Go modules
-   Documentation to reflect these changes

#### New Features 

-   License can be specified by their SPDX identifiers [#&#8203;1159](https://togithub.com/spf13/cobra/issues/1159)
-   `MatchAll` allows combining several PositionalArgs to work in concert. This now allows for enabling composing `PositionalArgs` [#&#8203;896](https://togithub.com/spf13/cobra/issues/896)

#### Bug Fixes 🐛

-   Fixed multiple error message from cobra `init` boilerplates [#&#8203;1463](https://togithub.com/spf13/cobra/issues/1463) [#&#8203;1552](https://togithub.com/spf13/cobra/issues/1552) [#&#8203;1557](https://togithub.com/spf13/cobra/issues/1557)

#### Testing 👀

-   Now testing golang 1.16.x and 1.17.x in CI [#&#8203;1425](https://togithub.com/spf13/cobra/issues/1425)
-   Fix for running diff test to ignore CR for windows [#&#8203;949](https://togithub.com/spf13/cobra/issues/949)
-   Added helper functions and reduced code reproduction in `args_test` [#&#8203;1426](https://togithub.com/spf13/cobra/issues/1426)
-   Now using official `golangci-lint` github action [#&#8203;1477](https://togithub.com/spf13/cobra/issues/1477)

#### Security 🔏

-   Added GitHub dependabot [#&#8203;1427](https://togithub.com/spf13/cobra/issues/1427)
-   Now using Viper `v1.10.0`
    -   There is a known CVE in an *indirect* dependency from `viper`: [spf13/cobra#1538. This will be patched in a future release

#### Documentation 📝

-   Multiple projects added to the `projects_using_cobra.md` file: [#&#8203;1377](https://togithub.com/spf13/cobra/issues/1377) [#&#8203;1501](https://togithub.com/spf13/cobra/issues/1501) [#&#8203;1454](https://togithub.com/spf13/cobra/issues/1454)
-   Removed ToC from main readme file as it is now automagically displayed by GitHub [#&#8203;1429](https://togithub.com/spf13/cobra/issues/1429)
-   Documentation correct for when the `--author` flag is specified [#&#8203;1009](https://togithub.com/spf13/cobra/issues/1009)
-   `shell_completions.md` has an easier to use snippet for copying and pasting shell completions [#&#8203;1372](https://togithub.com/spf13/cobra/issues/1372)

#### Other 💭

-   Bump version of  `cpuguy83/go-md2man` to v2.0.1 [#&#8203;1460](https://togithub.com/spf13/cobra/issues/1460)
-   Removed `lesser` typo from the GPL-2.0 license [#&#8203;880](https://togithub.com/spf13/cobra/issues/880)
-   Fixed spelling errors [#&#8203;1514](https://togithub.com/spf13/cobra/issues/1514)

*Thank you to all our amazing contributors* 🐍🚀

</details>

---

### Configuration

📅 **Schedule**: At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

 **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by [WhiteSource Renovate](https://renovate.whitesourcesoftware.com). View repository job log [here](https://app.renovatebot.com/dashboard#github/GoogleCloudPlatform/alloydb-auth-proxy).
akdev1l pushed a commit to akdev1l/rpms-toolbox that referenced this issue Aug 27, 2022
Earlier Viper was being pulled in by Cobra, and hence wasn't explicitly
listed as a BuildRequires.  However, Cobra 1.4.0 removed the Viper
dependency [1], so it needs to be explicitly listed.

There's no need to do a build just for this.

[1] Cobra commit 5b2b9e9f61d36ccb
    spf13/cobra#1597
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants