Can't import code.cloudfoundry.org/cli v8.4.0

[olyakrasnozhon]

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed github issues that may be related to my problem.
• I tried updating to the latest version of the CF CLI to see if it fixed my problem.
• I attempted to run the command with CF_TRACE=1 to help debug the issue.
• I am reporting a bug that others will be able to reproduce.

Describe the bug and the command you saw an issue with
I need to start using v3 client instead of v2 in my terraform-provider-cf. After some investigation I see that the new resources and their CRUD APIs I need are placed in code.cloudfoundry.org/cli v8.4.0.
I can't import this library directly, the error is -
"go get: code.cloudfoundry.org/cli@v8.4.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v8".

I went over another libraries that I probably could use:

• https://github.com/cloudfoundry-community/go-cfclient (latest)
• https://github.com/cloudfoundry-community/cloudfoundry-cli (latest - v0.0.11-complete-api)
  But they don't contains the newest APIs: for instance, go-cfclient contains the resource we need v3ServiceCredentialsBinding, but doesn't contain Create/Delete APIs for it.

What happened
I need your help to find the way to import appropriate library to my terraform-provider-cloudfoundry in order to be able to use all the resources and APIs that implemented in code.cloudfoundry.org/cli@v8.4.0.

Exact Steps To Reproduce

1. In any of go-projects run "go get code.cloudfoundry.org/cli@v8.4.0"
2. Expected error is "go get: code.cloudfoundry.org/cli@v8.4.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v8".
3. Look for CreateServiceCredentialsBinding here:

• https://github.com/cloudfoundry-community/cloudfoundry-cli/tree/master/api/cloudcontroller/ccv3
• https://github.com/cloudfoundry-community/go-cfclient
• https://github.com/cloudfoundry/cli/tree/v8.4.0

Notes regarding V6 and V7 CLI support:

• V6:
  • Minimum supported version of CF Deployment: v7.0.0 (CAPI Release: 1.74.0 (APIs 2.128.0 and 3.63.0))
  • Maximum supported version of CF Deployment: v13.4.0 (CAPI Release: 1.94.0 (APIs 2.149.0 and 3.84.0))
• V7:
  • Minimum supported version of CF Deployment: v13.5.0 (CAPI Release: 1.95.0 (APIs 2.150.0 and 3.85.0))

[a-b]

Hi @olyakrasnozhon. Thanks for pointing our attention, this issue seems similar to #2228 where @alex-gilin reported that the latest version of CF CLI that was published to https://pkg.go.dev/github.com/cloudfoundry/cli?tab=versions is 7.1.0

The fastest workaround for you to start using V3 would be go install code.cloudfoundry.org/cli@v7.1.0. Please consider pinging interrupt in #CLI Slack and ask to look at why v8 is not available.

[LukasHeimann]

Hi @a-b,

do you know how we can be added to the slack channel? It seems you have to be invited; you can only sign up by contacting some unknown administrator...

Looking at the guide (https://pkg.go.dev/about#adding-a-package), adding a package should be straight forward. However, there seems to be some sort of prerequisite that is not met with newer versions and https://proxy.golang.org/code.cloudfoundry.org/cli/@v/v8.4.0.info only gives an error response.

Edit: Most likely this is because with 7.2.0, a move to go modules was done (9f5601b), and that requires things to be different to work on pkg.go.dev... Unfortunately, I'm no go expert, so I'm a bit clueless as to what a fix might look like...

[LukasHeimann]

Looking at https://go.dev/doc/modules/release-workflow#breaking, the fix seems to be a change to https://github.com/cloudfoundry/cli/blob/v8.4.0/go.mod#L1

- module code.cloudfoundry.org/cli
+ module code.cloudfoundry.org/cli/v8

In the module’s go.mod file, revise the module path to append the new major version number, as in the following example:
example.com/mymodule/v2
Given that the module path is the module’s identifier, this change effectively creates a new module. It also changes the package path, ensuring that developers won’t unintentionally import a version that breaks their code. Instead, those wanting to upgrade will explicitly replace occurrences of the old path with the new one.

As you never import the module anywhere else during your development, I assume this would be an easy fix without breaking much on your end. Consumers could then go on to import on their end without problems:

require (
	code.cloudfoundry.org/cli/v8 v8.4.1
)

Unfortunately, this will only work if a tag (v8.4.1 in the consuming example below) is created that includes this minimal change. Can this be done from your side?

[LukasHeimann]

Showcased via the a quick fork: https://github.com/LukasHeimann/cloudfoundrycli/blob/v8/go.mod
After creating the repo and changing the go.mod file, I only created a new release tag (due to repo-renamings, it is at v8.4.3), called the go-proxy to make it available (https://proxy.golang.org/github.com/lukasheimann/cloudfoundrycli/v8/@v/v8.4.3.info) and there it is: https://pkg.go.dev/github.com/LukasHeimann/cloudfoundrycli/v8

This is really a minimal change, so please consider adding it and releasing a fresh version. If I shall contribute a PR, please let me know, but, as said, this is really minimal and more of an organizational topic. Thank you again for considering!

Kind regards
Lukas

Edit: a bunch of modules use absolute imports, so this might need to be changed as well, you will need to run a global string replace "code.cloudfoundry.org/cli([^-]) -> "code.cloudfoundry.org/cli/v8$1 as well, making this a bit of a larger change honestly... I used sed -i 's|"code.cloudfoundry.org/cli/|"github.com/LukasHeimann/cloudfoundrycli/v8/|g' $(find . -not -path '*/.*' -type f) to automate this in my repository.

[KevinJCross]

This relates to #2318 as well

[KevinJCross]

@LukasHeimann did you open a PR on this ?

[LukasHeimann]

Not yet, as I haven't heard back from the maintainers. This would be a really huge change: 2,193 changed files with 9,192 additions and 9,192 deletions. This is nothing you can't just simply do, honestly...

[KevinJCross]

TBH, if you open a PR it at least starts the process. Considering its mostly mostly search and replace and should be validated by the compiler this could be easy to review.
Bear in mind OSS guys are probably too overwelmed to look at it so if you make it easy it might get merged.

[KevinJCross]

@LukasHeimann If not Ill have a quick look at opening a PR.

[KevinJCross]

Ok the biggest issue to migrate to a /v8 is the archived dependency cfnetworking-cli-api that is used in actor/cfnetworkingaction and command/v7/shared/new_networking_client.go until this is fixed ( i.e. just copying or officially submoduled into the repository or the v7 stuff is removed) I dont think it is possible.

[KevinJCross]

Hi @olyakrasnozhon. Thanks for pointing our attention, this issue seems similar to #2228 where @alex-gilin reported that the latest version of CF CLI that was published to https://pkg.go.dev/github.com/cloudfoundry/cli?tab=versions is 7.1.0

The fastest workaround for you to start using V3 would be go install code.cloudfoundry.org/cli@v7.1.0. Please consider pinging interrupt in #CLI Slack and ask to look at why v8 is not available.

This is not possible because there was no mod file so the versions of its deps are not the same anymore and we get
module [github.com/vito/go-interact@latest](https://github.com/vito/go-interact@latest) found (v1.0.1), but does not contain package [github.com/vito/go-interact/interact/terminal](https://github.com/vito/go-interact/interact/terminal)

This means that no one can import any of this cli code for re-use

[a-b]

Hello, and sorry for the long reply. We're open for PRs.

[jcvrabo]

I'm bumping the issue as it becomes a bit of a hassle to develop plugins in case we do want to use the v8 cli. I couldn't find a PR for it, is there one or is this actively being looked at?

thanks.

[jcvrabo]

As an extra information, this becomes an actual issue, instead of just a hassle, as since the latest importable version is v7.1.0, which doesn't have a go.mod, all the dependencies will be taken from their latest versions, which will cause issues due to breaking changes. As an example, if I simply import github.com/cloudfoundry/cli, I will get github.com/cloudfoundry/cli v7.1.0+incompatible (the incompatible part pointing out that it's not a go module) and when resolving the dependencies you end up getting:

go: downloading github.com/cloudfoundry/cli v7.1.0+incompatible
go: downloading github.com/mattn/go-isatty v0.0.19
go: downloading github.com/rivo/uniseg v0.4.4
go: downloading google.golang.org/genproto/googleapis/rpc v0.0.0-20230807174057-1744710a1577
github.com/cloudfoundry/cli imports
        code.cloudfoundry.org/cli/util/ui imports
        github.com/vito/go-interact/interact/terminal: cannot find module providing package github.com/vito/go-interact/interact/terminal
github.com/cloudfoundry/cli imports
        code.cloudfoundry.org/cli/command/common imports
        code.cloudfoundry.org/cli/actor/sharedaction imports
        code.cloudfoundry.org/cli/util/clissh imports
        github.com/moby/moby/pkg/term: cannot find module providing package github.com/moby/moby/pkg/term

making it impossible to develop the plugin without individually going to each dependency failing, tracing back the last compatible version for that dependency and manually adding it to your go.mod. A bit less than desirable and perhaps not occurring to everyone.