Hydra: Go SDK is not "go get"-able

Created on 6 May 2019 · 53Comments · Source: ory/hydra

Describe the bug

When implementing a Hydra login/consent provider, I'd love to have a small Hydra Go SDK that's go get-able in a simple way without having to depend on the entire Hydra project and all its dependencies.

From what I can tell from the docs, I'm supposed to be able to run go get -u -d github.com/ory/hydra/sdk/go/.... This gives the following error message:

% go get -u -d github.com/ory/hydra/sdk/go/...
go: github.com/go-resty/[email protected]: parsing go.mod: unexpected module path "gopkg.in/resty.v1"
go: error loading module requirements

I see something similar has been reported before in #1388, and it was resolved with a commit to some docs implying the go get command I ran above.

To Reproduce

Start a new Go project using Go modules (outside of $GOPATH) by running go mod init github.com/myuser/myproject
Install the Hydra Go SDK by running go get -u -d github.com/ory/hydra/sdk/go/...
Observe an error message trying to resolve a Hydra Go SDK dependency.

Expected behavior

I was hoping to get a minimal dependency on the Swagger-generated Go-SDK in sdk/go/hydra/. Right now I'm workarounding it by just pulling in the entire Hydra project (go get github.com/ory/hydra) but this pulls in a huge host of dependencies that are not in use by the Go SDK.

Version:

Environment: Locally using Go 1.12.4 (darwin/amd64)
Version 1.0.0-rc.11

Source

tanordheim

Most helpful comment

I will try to update the docs soon to make this process less painful!

aeneasr on 23 Jul 2019

👍4

All 53 comments

This has been resolved a while ago, you're pulling an old version. If you're in go modules maybe try go get -u -d github.com/ory/hydra/sdk/go/...@master

aeneasr on 6 May 2019

That fails with another error:

% go get -u -d github.com/ory/hydra/sdk/go/...@master
go: finding github.com/ory/hydra/sdk/go/... master
go: finding github.com/ory/hydra/sdk/go master
go: finding github.com/ory/hydra/sdk master
go: finding github.com/ory/hydra master
go: downloading github.com/ory/hydra v1.0.0-rc.11.0.20190506141423-84573d9a578a
go: extracting github.com/ory/hydra v1.0.0-rc.11.0.20190506141423-84573d9a578a
go get github.com/ory/hydra/sdk/go/...@master: missing github.com/ory/hydra/sdk/go/.../go.mod at revision 84573d9a578a

tanordheim on 6 May 2019

GO111MODULE=on go get -u -d github.com/ory/hydra/...@master

alternatively:

GO111MODULE=off go get -u -d github.com/ory/hydra/sdk/go/...

This is a constraint of go modules at the moment.

aeneasr on 6 May 2019

GO111MODULE=on go get -u -d github.com/ory/hydra/...@master prints the same error as in my previous comment. GO111MODULE=off go get -u -d github.com/ory/hydra/sdk/go/... downloads the module but (naturally) doesn't add it to go.mod.

Is the takeaway here then that the Go SDK does not work when you use a project outside of GOPATH using Go modules for the time being? The docs wasn't really clear on this, hence my confusion :)

tanordheim on 6 May 2019

Right, I think it needs to be GO111MODULE=on go get -u -d github.com/ory/hydra@master - the ... notation is something pre-go modules!

aeneasr on 6 May 2019

Yeah, and that then pulls down a massive amount of dependencies even though the code in sdk/go/hydra/... depends on more or less none of it - it's what I'm currently using :)

Any plans to make the Go SDK more standalone, to avoid it having such a large dependency tree come with it?

tanordheim on 7 May 2019

We're using the SDK internally so that's not possible. I think one way to solve it is to add another go.mod within sdk/go/hydra that declares dependencies explicitly for the SDK.

aeneasr on 8 May 2019

Yeah that'd be great actually, I noticed adding the entire hydra project as a dependency to get a generated Swagger-client for the 4 endpoints we used caused our CI pipelines for the relevant project to increase so much (go mod cache went from 80 to 800MB when adding hydra as a dependency) that we ended up just embedding the Go SDK directly in our project. Having the SDK itself be go get-able would be really sweet :)

tanordheim on 8 May 2019

Can you try if GO111MODULE=on go get github.com/ory/hydra/sdk/go/hydra@fix-1422 works as expected?

aeneasr on 8 May 2019

Damn, this breaks the internal build. FFS :D

aeneasr on 8 May 2019

Ok, found the issue and resolved it. I think it's possible after all!

aeneasr on 8 May 2019

I'm bumping a closed issue instead of reopening a new one since I still can't get this working and I don't know if it's me being thick or if this just didn't work :)

I see this change has been merged to master so go get now returns this:

% GO111MODULE=on go get github.com/ory/hydra/sdk/go/hydra@master
go: finding github.com/ory/hydra/sdk/go/hydra master
go: finding github.com/ory/hydra/sdk/go/hydra latest
go: finding github.com/ory/hydra/sdk/go latest
go: finding github.com/ory/hydra/sdk latest
go: github.com/go-resty/[email protected]: parsing go.mod: unexpected module path "gopkg.in/resty.v1"
go: error loading module requirements

tanordheim on 8 May 2019

Grr, I don't know why it's resolving an old commit :/

aeneasr on 8 May 2019

According to the Modules FAQ in the Go repository I think some clever tagging in the Hydra repository is required in order for go get to detect this? I have to admit I've never had submodules like this within the same repository before so I'm not fully aware on the black magic required to get this working.

tanordheim on 8 May 2019

I tried wiping my $GOPATH/pkg/mod as well, and still get the same resty-related error as above.

tanordheim on 8 May 2019

Hm, I can also reproduce this. I don't get why it's resolving to some random commit. I've also tried GO111MODULE=on go get github.com/ory/hydra/sdk/go/hydra@5eeb162ccef637f04d960ba1c6579af3c730c13a which should fetch the latest commit but it just doesn't...

aeneasr on 8 May 2019

Running go mod download github.com/ory/hydra/sdk/go/hydra@master downloads the correct version of the code to my $GOPATH/pkg/mod/github.com/ory/hydra/sdk/go/[email protected] directory as far as I can tell (tried with a clean directory). Running go mod download within the target directory directory also succeeds, as well as go build ./... within the same directory.

Not quite sure what go get is doing differently, I don't know the internals here that well; verbose output:

% GO111MODULE=on go get -v github.com/ory/hydra/sdk/go/hydra@master
go: finding github.com/ory/hydra/sdk/go/hydra master
go: finding github.com/ory/hydra/sdk/go/hydra latest
go: finding github.com/ory/hydra/sdk/go latest
go: finding github.com/ory/hydra/sdk latest
Fetching https://golang.org/x/oauth2/clientcredentials?go-get=1
Fetching https://golang.org/x/oauth2?go-get=1
Parsing meta tags from https://golang.org/x/oauth2/clientcredentials?go-get=1 (status code 200)
get "golang.org/x/oauth2/clientcredentials": found meta tag get.metaImport{Prefix:"golang.org/x/oauth2", VCS:"git", RepoRoot:"https://go.googlesource.com/oauth2"} at https://golang.org/x/oauth2/clientcredentials?go-get=1
get "golang.org/x/oauth2/clientcredentials": verifying non-authoritative meta tag
Parsing meta tags from https://golang.org/x/oauth2?go-get=1 (status code 200)
Fetching https://golang.org/x/oauth2?go-get=1
get "golang.org/x/oauth2": found meta tag get.metaImport{Prefix:"golang.org/x/oauth2", VCS:"git", RepoRoot:"https://go.googlesource.com/oauth2"} at https://golang.org/x/oauth2?go-get=1
Parsing meta tags from https://golang.org/x/oauth2?go-get=1 (status code 200)
go: finding golang.org/x/oauth2 latest
go: finding golang.org/x/oauth2/clientcredentials latest
go: github.com/go-resty/[email protected]: parsing go.mod: unexpected module path "gopkg.in/resty.v1"
go: error loading module requirements

go mod graph does not indicate a dependency to resty anywhere.

I tried creating a blank project where I add the dependency directly go go.mod and that actually works; go mod download works, go mod vendor adds the Hydra subtree I expect to vendor/.

I suspect this is some black magic in go get where it tries to resolve the module using version tags or something like the stuff outlined in the Module FAQ. I'm not sure just adding a go.mod to a subpath is intended to work with go get just like that. But, again, I don't know the internals here all that well :/

tanordheim on 8 May 2019

Hm but seeing that we had this issue in the original repo as well (without the submodule) indicates that it's not resolved, right?

Would you be open to take this upstream in the Gopher slack (channel modules) or alternatively an issue in Go itself? I'd really appreciate it!

aeneasr on 8 May 2019

Yeah I'm drawing blanks here. I tried creating a minimal reproduction in this repository with the following tags:

v1.0.0
sdk/go/hydra/v0.0.1

With this repo I can successfully go get all of the following:

github.com/tanordheim/hydra-sdk-mod-test@master
github.com/tanordheim/[email protected]
github.com/tanordheim/hydra-sdk-mod-test/sdk/go/hydra@master
github.com/tanordheim/hydra-sdk-mod-test/sdk/go/[email protected]

I might as you say just be that it somehow ends up referencing the wrong SHA somewhere, I have no idea - no sensible output from go get -v tells me why at least. I can try poking some people in the Gopher slack just to see later.

Would you be able to try and add a tag sdk/go/[email protected] or something to this repository temporarily to see if that specific version is go get-able just to have that information at hand before I ask someone else about this?

tanordheim on 8 May 2019

done

aeneasr on 8 May 2019

It needs the full path sdk/go/[email protected], not just the version number :)

tanordheim on 8 May 2019

You mean that I should create a version with tag sdk/go/[email protected]?

aeneasr on 8 May 2019

Yeah - that is how versioning of nested Go modules work according to the Module FAQ linked previously. Go modules intend that nested modules like this are independently versioned (or at least can be), I'm just curious if that affects the behavior here any.

tanordheim on 8 May 2019

Oh ok I see - I didn't even know that that's a valid git tag :D

aeneasr on 8 May 2019

done

aeneasr on 8 May 2019

% go get -v github.com/ory/hydra/sdk/go/[email protected]
go: finding github.com/ory/hydra/sdk/go/hydra v0.0.1
go: finding github.com/ory/hydra/sdk/go v0.0.1
go: finding github.com/ory/hydra/sdk v0.0.1
Fetching https://github.com?go-get=1
Parsing meta tags from https://github.com?go-get=1 (status code 200)
go get github.com/ory/hydra/sdk/go/[email protected]: unknown revision sdk/go/hydra/v0.0.1

Yeah I got nothing. I'll see if the Gopher slack has some more ideas on what's going on here later today.

tanordheim on 8 May 2019

ok - I'll leave the git tags in there just in case you need it to prove a point. Feel free to ping/include me in the convo. My gopher slack id is aeneas

aeneasr on 8 May 2019

Ah the tag is still broken - my bad, it's supposed to be sdk/go/hydra/v0.0.1. Can you correct that? / instead of @ before the version number.

tanordheim on 8 May 2019

done!

aeneasr on 8 May 2019

I lost track of the convo on slack, but I think your comment sums it up perfectly:

we’re basically trying to see if there would be a way to just depend on a small set of generated code inside the ory/hydra repository that can be used for clients implementing their API - instead of having to pull down the whole ory/hydra module with all its dependencies since 99% of it is not needed

This was actually the case with glide and godep - they purged any src that was not required. I think the issue with go mod is that it fetches the full git history which is rather large for an older project and then (maybe) excludes the dirs not needed.

That's also why go mod proxy should resolve a lot of the issues there as it is (hopefully) capable of some optimizations.

I think we have to make a trade-off here. We're relying on the generated Go SDK internally for all CLI commands. We're also running tests against the SDK. This ensures that swagger definitions are on par with the actual implementation. Moving that to an external repo will (a) increase complexity when making swagger changes (b) increase dev env complexity or (c) make it impossible to actually test the SDK. I'm therefore strongly against that. In fact, I believe that Go Modules should be capable of resolving partial dependencies as it was the case with Glide/Godep.

As a workaround there are these options so far:

Without go modules: GO111MODULE=off go get -u -d github.com/ory/hydra/sdk/go/...
With go modules: GO111MODULE=on go get github.com/ory/hydra@master
Generating SDK and checking it into the dependent project: GO111MODULE=off swagger generate client -f ./docs/api.swagger.json -t sdk/go/hydra -A Ory_Hydra (requires installation of go swagger)
With Go Proxy: GOPROXY='https://gocenter.io' GO111MODULE=on go get github.com/ory/hydra@master

It's still very weird that running anything else is trying to fetch go-resty. No idea why that is...

I've also added the slack convo to the github issue: https://github.com/golang/go/issues/31713#issuecomment-491224959

aeneasr on 10 May 2019

Yeah I don't understand why it goes to fetch go-resty either, but as someone on Slack mentioned it seems like this might be related to the fact that sdk/go/hydra/ is both it's own module right now on master, as well as part of the ory/hydra module previously in the history of the repository and that causes problems and confusion for the module resolver. I don't understand fully how that can be, but the internals of this stuff is probably a thousand times more complicated than it seems on the outside.

The go mod proxy isn't really possible in our use case as we also pull some private dependencies which the proxy doesn't support - and there is as far as I can tell no way of only using proxy for a certain set of dependencies. The "proper" fix here would be as you say to have the Go SDK for Hydra be in its own repository and pull it into the ory/hydra repository as a dependency in it's go.mod. I get that this might complicate things though for you guys though so it might not be a viable path to take things - maybe it could be an option to have a separate repository in _addition_ to keeping it in ory/hydra? Some CI pipeline somewhere that takes any new release of ory/hydra, snags the Go SDK from it and pushes it to another repository where it creates the same tagged release there.

Embedding the SDK in client code that needs it also isn't a horrible fix though, this is fairly stable APIs I presume and it's not likely you'd need to do a lot of updates on them - especially not without also updating the version of Hydra you're running. Maybe some of this could be useful in the docs as some pointer on how you could choose to do things if you don't want to depend on the entire Hydra project?

tanordheim on 10 May 2019

Some CI pipeline somewhere that takes any new release of ory/hydra, snags the Go SDK from it and pushes it to another repository where it creates the same tagged release there.

Yeah, I think that would probably be the most reasonable course of action to circumvent this issue while keeping internals untouched but also providing a way for the SDK to not suck :D

aeneasr on 10 May 2019

Hi,
today I encountered this same issue.

Trying to use the go sdk (go 1.12 with mod) results in a massive download of all the dependencies required by the hydra server.

Is the manual generation/copy of the sdk the suggested way to go, or there is a more straightforward way?

dvd0101 on 8 Jul 2019

I will try to update the docs soon to make this process less painful!

aeneasr on 23 Jul 2019

👍4

Hi, using golang 1.13 and can't get this working.

What do I need to write in go.mod file?

I've tried:

github.com/ory/hydra/sdk/go/hydra v0.0.1
github.com/ory/hydra v1.0.3

petuhovskiy on 24 Sep 2019

Does it fail with go: sourcegraph.com/sourcegraph/[email protected]: parsing go.mod: unexpected module path "github.com/sourcegraph/go-diff"? If so, I think this is caused by another regression introduced by the go 1.13 module changes.

aeneasr on 25 Sep 2019

I initialized new module with some code which uses Hydra SDK, and go get it. Here is the result:

[arthur@arch testh]$ go get -u -d github.com/ory/hydra/sdk/go/...
go: finding github.com/asaskevich/govalidator latest
go: finding github.com/PuerkitoBio/urlesc latest
go: finding golang.org/x/net latest
[arthur@arch testh]$ go build
build testh: cannot load github.com/ory/hydra/sdk/go/hydra: module github.com/ory/hydra/sdk/go/hydra@latest (v0.0.1) found, but does not contain package github.com/ory/hydra/sdk/go/hydra

petuhovskiy on 25 Sep 2019

You need to do $ GO111MODULE=on go get -u github.com/ory/hydra. github.com/ory/hydra/sdk/go/... will lead to problems / does not work :)

aeneasr on 25 Sep 2019

Same :(

[arthur@ARTHUR-ARCH testh]$ go mod init testh
go: creating new go.mod: module testh
[arthur@ARTHUR-ARCH testh]$ GO111MODULE=on go get -u github.com/ory/hydra
go: finding golang.org/x/sync latest
go: finding golang.org/x/tools latest
go: finding github.com/golang/gddo latest
go: finding github.com/xtgo/uuid latest
go: finding github.com/xeipuuv/gojsonreference latest
go: finding golang.org/x/sys latest
go: finding github.com/sqs/goreturns latest
go: finding golang.org/x/crypto latest
go: finding golang.org/x/oauth2 latest
go: finding github.com/gtank/cryptopasta latest
go: finding github.com/asaskevich/govalidator latest
go: finding github.com/PuerkitoBio/urlesc latest
go: finding github.com/segmentio/backo-go latest
go: finding github.com/meatballhat/negroni-logrus latest
go: finding golang.org/x/net latest
go: finding github.com/rubenv/sql-migrate latest
go: finding github.com/prometheus/client_model latest
go: finding github.com/xeipuuv/gojsonpointer latest
go: finding github.com/mohae/deepcopy latest
go: finding github.com/mendsley/gojwk latest
go: finding github.com/ory/go-acc latest
go: finding github.com/ory/gojsonreference latest
[arthur@ARTHUR-ARCH testh]$ go build
build testh: cannot load github.com/ory/hydra/sdk/go/hydra: module github.com/ory/hydra/sdk/go/hydra@latest (v0.0.1) found, but does not contain package github.com/ory/hydra/sdk/go/hydra

petuhovskiy on 25 Sep 2019

What if you force the version? GO111MODULE=on go get github.com/ory/[email protected]

aeneasr on 25 Sep 2019

After go get, dependency is saved in go.mod like github.com/ory/hydra v1.0.3 already

Maybe I have some weird behavior due to enabled goproxy (by default in 1.13)

Tried go get again:

[arthur@ARTHUR-ARCH testh]$ go mod init testh
go: creating new go.mod: module testh
[arthur@ARTHUR-ARCH testh]$ GO111MODULE=on go get github.com/ory/[email protected]
[arthur@ARTHUR-ARCH testh]$ go build
build testh: cannot load github.com/ory/hydra/sdk/go/hydra: module github.com/ory/hydra/sdk/go/hydra@latest (v0.0.1) found, but does not contain package github.com/ory/hydra/sdk/go/hydra
[arthur@ARTHUR-ARCH testh]$

My sample code that I use for this test:

package main

import (
    "net/url"
    "os"

    "github.com/ory/hydra/sdk/go/hydra"
    "github.com/ory/hydra/sdk/go/hydra/client"
    "github.com/ory/hydra/sdk/go/hydra/client/admin"
)

func initHydraAdmin() *admin.Client {
    adminURL := url.Parse(os.Getenv("HYDRA_ADMIN_URL"))
    cli := hydra.NewHTTPClientWithConfig(nil, &client.TransportConfig{Schemes: []string{adminURL.Scheme}, Host: adminURL.Host, BasePath: adminURL.Path})
    return cli.Admin
}

func main() {
    initHydraAdmin()
}

petuhovskiy on 25 Sep 2019

I hate go modules... Thank you for the detailed report, I will try to get to the bottom of this.

aeneasr on 25 Sep 2019

👍1

Got it working. There was an incorrect import path in my code, which was one of reason for found, but does not contain package error.

The successful way is to go get -u -d github.com/ory/hydra/sdk/go/... (with dots)

[arthur@ARTHUR-ARCH testh]$ go mod init testh
go: creating new go.mod: module testh
[arthur@ARTHUR-ARCH testh]$ go get -u -d github.com/ory/hydra/sdk/go  # gives the same error
go: finding github.com/ory/hydra/sdk latest
go: finding github.com/ory/hydra/sdk/go latest
go get github.com/ory/hydra/sdk/go: module github.com/ory/hydra@upgrade (v1.0.3) found, but does not contain package github.com/ory/hydra/sdk/go
[arthur@ARTHUR-ARCH testh]$ go get -u -d github.com/ory/hydra/sdk/go/...
go: finding github.com/ory/hydra/sdk latest
go: finding github.com/ory/hydra/sdk/go latest
go: finding github.com/PuerkitoBio/urlesc latest
go: finding github.com/asaskevich/govalidator latest
go: finding golang.org/x/net latest
[arthur@ARTHUR-ARCH testh]$ go build
[arthur@ARTHUR-ARCH testh]$

Fixed code:

package main

import (
    "net/url"
    "os"
    "log"

    "github.com/ory/hydra/sdk/go/hydra/client"
    "github.com/ory/hydra/sdk/go/hydra/client/admin"
)

func initHydraAdmin() *admin.Client {
    adminURL, err := url.Parse(os.Getenv("HYDRA_ADMIN_URL"))
    if err != nil {
        log.Fatal(err)
    }
    cli := client.NewHTTPClientWithConfig(nil, &client.TransportConfig{Schemes: []string{adminURL.Scheme}, Host: adminURL.Host, BasePath: adminURL.Path})
    return cli.Admin
}

func main() {
    initHydraAdmin()
}

petuhovskiy on 25 Sep 2019

Trying to update from 1.0.0 to 1.0.3 and got the error:

cannot load github.com/ory/hydra/sdk/go/hydra/client: ambiguous import: found github.com/ory/hydra/sdk/go/hydra/client in multiple modules:
github.com/ory/hydra v1.0.3 (/......../go/pkg/mod/github.com/ory/[email protected]/sdk/go/hydra/client)
github.com/ory/hydra/sdk/go/hydra v0.0.1(/......../go/pkg/mod/github.com/ory/hydra/sdk/go/[email protected]/client)

I'm using go 1.13.

I think if go sdk will be moved to own repository and own go module it will solve all the problems.
Now, in terms of go modules if we want to get the go sdk, the Go will pull all hydra because it is one go module. I cannot understand exactly what cause to Go to refer to hydra itself while it not imported directly ( i searched for my just grown up project and no direct imports of types from hydra) it could be issue of Go itself, but if the sdk not depend from hydra, moving it to own go module will solve this problem once and forever.

PS. I understand it could be not possible...

The error acually says that Go got confused between type Client in two different packages ( _github.com/ory/hydra v1.0.3_ and _github.com/ory/hydra/sdk/go/hydra v0.0.1_).
may be rename of one of types will help...

UPDATE:

I've found the way to fix my code by isolating hydra sdk in the package and providing interfaces to rest of the application. It resolves the conflict

UPDATE

Very strange... go build is successful, but go mod tidy fails with same error

pereslava on 26 Sep 2019

If you have github.com/ory/hydra/sdk/go/hydra as a dependency in your go modules code, please remove it.

You are correct, the SDK does not rely on any Go Code. A more intelligent vendoring mechanism would strip everything else and download the SDK only. I believe Go 1.13+ will solve this as time progresses with the Go Modules Proxy as Git is no longer required.

aeneasr on 28 Sep 2019

Thank you @aeneasr,
I tried it, but go build brings it again. Also i tried to reproduce it with minimal code similar to my project structure and cannot get this error. I'm already upgraded to go 1.13 and uses the proxy for modules.
In one hand it says that i have something wrong in my project, but in second go complains about tags:
0.0.1 ffor SDK, adn 1.0.5 (for now) for sdk inside hydra 1.0.5.
go modules looking for the tags with semver (proxy only packs the modules according to tags) could it be that SDK was tagged with 0.0.1? may be removing this tag will solve the problem...

pereslava on 29 Sep 2019

We once had that tag as an experiment of a submodule within a go module, but that tag and everything has been removed completely from git.

Make sure you did not include github.com/ory/hydra/sdk/go/hydra in your Go code directly.

aeneasr on 29 Sep 2019

@aeneasr I've found conflicting import. it is the *healph.Client. Bellow the code illustrating problem:

go.mod:

module github.com/pereslava/hydra-clp

go 1.13

require github.com/ory/hydra v1.0.5

main.go:

package main

import (
    "context"
    "fmt"
    "log"
    "net/url"

    "github.com/ory/hydra/sdk/go/hydra/client"
    "github.com/ory/hydra/sdk/go/hydra/client/admin"
    //  "github.com/ory/hydra/sdk/go/hydra/client/health"
)

var (
    p *client.OryHydra
    a *client.OryHydra
)

// Admin returns admin api or panic
func hAdmin() *admin.Client {
    if a == nil {
        hInit()
    }
    return a.Admin
}

// Init initialised hydra
func hInit() {
    log.Println("hydra -init")
    if a != nil && p != nil {
        return
    }
    publicURL, err := url.Parse("http://hydra_public")
    if err != nil {
        log.Fatal(err)
    }
    log.Println(publicURL.Path)
    adminURL, err := url.Parse("http://hydra_admin")
    if err != nil {
        log.Fatal(err)
    }
    log.Println(adminURL.Path)

    p = client.NewHTTPClientWithConfig(nil, &client.TransportConfig{Schemes: []string{publicURL.Scheme}, Host: publicURL.Host, BasePath: publicURL.Path})
    a = client.NewHTTPClientWithConfig(nil, &client.TransportConfig{Schemes: []string{adminURL.Scheme}, Host: adminURL.Host, BasePath: adminURL.Path})
}

// WaitReady waith for ready state of hydra
func hWaitReady(ctx context.Context) error {
    c := make(chan struct{}, 1)
    go func() {
        // log.Println("Wait hydra ready...")
        // isReadyParams := health.NewIsInstanceReadyParams()
        // for {
        //  res, err := p.Health.IsInstanceReady(isReadyParams)
        //  if err == nil && res.Payload.Status == "ok" {
        //      break
        //  }
        //  log.Println(err)
        //  time.Sleep(time.Second)
        // }
        c <- struct{}{}
    }()

    select {
    case <-ctx.Done():
        return fmt.Errorf("Hydra not ready: %w", ctx.Err())
    case <-c:
        log.Println("Hydra ready")
        return nil
    }
}

func main() {
    hInit()

    hWaitReady(context.Background())
}

Then unkomment the commented out code, you get the conflict.

I created repository with this code: https://github.com/pereslava/hydra-clp

It have 3 branches:

master - the code with commented heath query

build_error - the code is uncomennted, go build and go mod tidy fails

unknown_ver: - it created by removing go.sum, and cleanup require of go.mod, then go mod tidy and go build. It built but with version 1.0.0

pereslava on 29 Sep 2019

Sorry for abuse but finally problematic import is "github.com/ory/hydra/sdk/go/hydra/client/health" which does not exist anymore in ver 1.0.5, but existed in 0.0.1. It is definitely problem in client code...

pereslava on 29 Sep 2019

Ok so I think we can finally close this issue - all reported problems boiled down to broken import statements in the dependent code. There's still an option where we would move the SDK to another repository but that's for another time to decide.

aeneasr on 29 Sep 2019

I am facing the same problem. When I try to used github.com/ory/hydra/sdk/go/hydra package models the error message from VSCode says:

module github.com/ory/hydra/sdk/go/hydra@latest (v0.0.1) found, but does not contain package github.com/ory/hydra/sdk/go/hydra

jvaca92 on 20 Oct 2019

Please see the previous comments, you probably imported github.com/ory/hydra/sdk/go/hydra in your code. Remove that import, it is invalid.

aeneasr on 20 Oct 2019

Thanks, just import directly github.com/ory/hydra/sdk/go/hydra/client with admin and everything works perfectly. Sorry for not enough attention.

jvaca92 on 21 Oct 2019

Was this page helpful?

0 / 5 - 0 ratings

Related issues

Support fosite delegated transactions in SQL storage

aaslamin · 3Comments

Showcase: How and where are you using Hydra?

aeneasr · 3Comments

No CSRF value available in the session cookie happend in the guiding demo

LuoWei0731 · 7Comments

OpenID Connect Certification

aeneasr · 3Comments

Add SAML2 Bearer Assertion Grant Type

lpotherat · 7Comments