Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose an __atom as internal api, or ... #21

Open
blaggacao opened this issue Aug 7, 2024 · 1 comment
Open

Expose an __atom as internal api, or ... #21

blaggacao opened this issue Aug 7, 2024 · 1 comment

Comments

@blaggacao
Copy link
Contributor

blaggacao commented Aug 7, 2024

https://github.com/ekala-project/atom/blob/master/src%2Fatom%2Fcompose.nix#L28

... or only expose selected keys?

Expose selected keys meant for regular usage while exposing the raw __manifest (maybe better than __atom), for introspection, potentially only when feature flagged (similar to tests).

This forces us to expose a stable api of the manifest to internal code and makes it more stable, while limiting a bit its (hypothetically useful) flexibility.

Some of the keys to expose would be:

  • atom — for its name & version
  • features — for feature flagging
  • matrix values (tbd)
@nrdxp
Copy link
Member

nrdxp commented Aug 7, 2024

yes, I was thinking along the same lines, for now the whole config is exposed, since we don't have a fully stable config surface yet. Once the core is a bit more stabilized we can decide what is appropriate to pass here and what isn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants