[FEATURE] Follow official Go guidance on how to organize a module? about go-sdk HOT 9 CLOSED

github.com/open-feature/go-sdk/openfeature would be a nice import path, because it helps goimports to automatically import the package when it's used in a file.

You can probably do this without a breaking change using type aliases to make the types of the pkg/openfeature package aliases of the types in the openfeature package, and having functions in the pkg/openfeature package call their identically-named functions in the openfeature directory. Constants can likewise be aliases into the the openfeature package.

The memprovider package could take a similar approach.

I think that would preserve all identifiers and behaviors, while only maintaining a single implementation of the behaviors. Future identifiers wouldn't need to be added to pkg/openfeature. And because the types are considered the same types, there shouldn't be any compilation impact.

from go-sdk.

I've opened #232 and #233 with proofs of concept of the github.com/open-feature/go-sdk/openfeature and github.com/open-feature/go-sdk import paths, respectively. I don't have time to do the harder work (validation), but the branches build and the tests pass. I don't have a consumer of the package at-hand to verify the compatibility, unfortunately.

from go-sdk.

I think this is a great idea. Thanks @paddycarver, for putting together the PoC!

@craigpastro are you happy with this solution?

from go-sdk.

Thank you @paddycarver for the POC PRs. I checked them and I'm in favor of the new packaging proposed through #232 (root/pkg/openfeature -> root/openfeature). I think this packaging is ideal, solves the packaging issue as well as isolates logic instead of having it at root level (i.e- compared to #233)

I tried adapting go sdk providers and all looks fine. However, this make lint failures which means we have to update all references to the latest packaging.

@toddbaert shall we proceed with this change?

I don't have a problem with correcting the lint errors. I think this is a very worthwhile change.

I'm very happy with this solution.

from go-sdk.

@Kavindu-Dodan @thisthat @bacherfl @RealAnna do you folks have any opinions on this?

If it's desirable (seems like it might be) is it at all possible to do this in a non-breaking way (support both?)?

from go-sdk.

I think this is worth exploring, especially if we could make this a non-breaking change. @paddycarver, would you be willing to put together a proof of concept using type aliases?

from go-sdk.

Thank you @paddycarver for the POC PRs. I checked them and I'm in favor of the new packaging proposed through #232 (root/pkg/openfeature -> root/openfeature). I think this packaging is ideal, solves the packaging issue as well as isolates logic instead of having it at root level (i.e- compared to #233)

I tried adapting go sdk providers and all looks fine. However, this make lint failures which means we have to update all references to the latest packaging.

@toddbaert shall we proceed with this change?

from go-sdk.

I think this is a great solution that avoids breakage. Thanks @paddycarver 🎉

from go-sdk.

Created #234 to track follow-up tasks once this issue is resolved with the proposed fix at #232

from go-sdk.