Comments (9)
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.
Related Issues (20)
- [ci] Configure renovate
- [ci] Configure cycloneDX for SBOM generation
- [TESTS] Introduce fuzzing tests
- [ci] Implement renovate config that watches test-harness version
- Absorb extracted test suite from go-sdk-contrib
- [FEATURE] Validate EvaluationContext's keys/values are UTF-8?
- [FEATURE] Generics for v2 release of go-sdk HOT 1
- [FEATURE] Propagate request context HOT 3
- [BUG] Cache isn't invalidated properly HOT 5
- Update README to be consistent with other SDKs
- Changes to support spec `v0.6.0` compliance HOT 4
- implement named client support: open-feature/spec@4cf8229 HOT 1
- implement initialization/shutdown: open-feature/spec@a4ffec3
- Implement event support HOT 1
- Conform to spec `v0.7.0` HOT 6
- event handlers should run immediately if the associated provider is in the state associated with that handler already
- [FEATURE] Follow up for 227 HOT 2
- [BUG] Panic when following getting started tutorial HOT 2
- [FEATURE] Blocking provider mutator HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-sdk.