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

Setting the "header" for a list #2028

Closed
pecigonzalo opened this issue Sep 4, 2020 · 6 comments
Closed

Setting the "header" for a list #2028

pecigonzalo opened this issue Sep 4, 2020 · 6 comments

Comments

@pecigonzalo
Copy link

Im using Dhall to generate Kuberentes and I believe it would be great to have some way to denote a "header" for list.

For example

let this = [ { foo = "this", bar = "that" }, { foo = "fizz", bar = "buzz" } ]

in  this

Renders

- bar: that
  foo: this
- bar: buzz
  foo: fizz

I would be great to have some semantics to say "I want foo as my - value". This would be really helpful in container definitions, as it would mean we can pin either image or name or something meaningful to the list -. This gets generally set to args or some other setting which does not identify the container.

Example

let this : Type = { foo |= Text, bar = Text }

This seems like a minor annoyance, but when you have a list with multiple containers and each container with a long list of defined settings, it gets really hard to parse them.

An alternative idea would be to follow the order set by the Type definition if one is specified, which would not work for the previous example, but would allow me to define a type to explicitly set an order.

PS: I think it would be great for Kubernetes to use servicename: and define these values inside of the key, as its done in Docker Compose.

@Gabriella439
Copy link
Collaborator

I'll transfer this issue to https://github.com/dhall-lang/dhall-haskell since this is an issue for the dhall-to-yaml tool

@Gabriella439 Gabriella439 transferred this issue from dhall-lang/dhall-lang Sep 4, 2020
@Gabriella439
Copy link
Collaborator

Gabriella439 commented Sep 4, 2020

This appears to be the same issue as #2028 #1187

@pecigonzalo
Copy link
Author

Thanks! I was not sure if this was something to be implemented in the core code, as the 2nd option would apply to all output.

The link seems to self reference this issue.

@Gabriella439
Copy link
Collaborator

Whoops! I fixed the link

@pecigonzalo
Copy link
Author

pecigonzalo commented Sep 4, 2020

Reading the linked issue, that maps perfectly to that second suggestion, and would be a more complete solution. I'm happy to close this one and continue over there, but I defer to your judgment.

@Gabriella439
Copy link
Collaborator

Alright, then I'll close this out in favor of the other issue

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