feat: openfeature pull command

[jsalaber]

Summary

• init command creates a .openfeature.yaml to store flagSourceUrl using the --flag-source-url
• adds a new pull command that fetches a flag configuration from a flagSourceUrl configured in the init command
• pull command prompts the user for default values if the source configuration doesn't define default values
• overwrites the manifest with the source url flags
• supports using local file uri or http: file:// or https://

Related Issues

#3

Notes

• refactored out the Load function from flagset due to circular dependency when trying to use flagset type in the manifest package
• new LoadFromSourceFlags takes the type from a source configuration and compares it to different types that could match, e.g. Boolean, bool, boolean

Todo

• Support different auth types other than auth token as a header, and figure out a way to store it securely without needing to pass it in as a flag in the pull command

[dominikhaska]

I think it would be good to add some tests - there is an in memory filesystem in generate_test.go so it could be used and probably faking network should not be that hard.

[jsalaber]

@dominikhaska added a couple of tests for the pull command!

[kriscoleman]

this is looking great, thanks!
I think this is a great first step to push/pull/diff.

I was also ideating on a pull command too, and had wondered what kind of sources we might pull from.
Just food for thought, I imagined we might have a concept of Sources, a source might be as simple as a public URL to a manifest file, or an authed endpoint like here, a file stored in git, or from an instance of openfeature itself. We might be able to contribute different source provider types (GitSource, OpenFeatureApiSource, URLSource, etc.), to make this extensible and able to encapsulate domain specifics for different sources.

[beeme1mr]

I was also ideating on a pull command too, and had wondered what kind of sources we might pull from.
Just food for thought, I imagined we might have a concept of Sources, a source might be as simple as a public URL to a manifest file, or an authed endpoint like here, a file stored in git, or from an instance of openfeature itself. We might be able to contribute different source provider types (GitSource, OpenFeatureApiSource, URLSource, etc.), to make this extensible and able to encapsulate domain specifics for different sources.

I was thinking about that too. Perhaps we could do something similar to flagd where we accept a --uri flag and use the protocol identifier to determine how to pull from the source. We could start by supporting only http, but we could easily add support for git, ssh, s3, and more.

[beeme1mr]

I think the flag source object should look like this:

{
  "flags": [
     {
        "key" "test",
        "type": "boolean",
        "defaultValue": false
     }
  ]
}

This will allow us to add additional top-level properties without requiring a breaking change.

[jsalaber]

Do you mean the source should return with a top level flags property or when we unmarshal the data to pass around a data object that has the flags property?

[beeme1mr]

The source is what I had in mind.