Output in the same order as defined

[bruno-delfino1995]

Is there any practical reason, or laid out by the spec, on why the fields get ordered when manifesting?

I plan on using the order of the fields to determine how kct applies resources to the cluster. But as the fields get ordered during manifestation, I'm a bit lost and can't find an alternative on what else to use. Honestly, setting my interests with kct aside, I find it a little strange to have the rendered fields in a different order than what I defined in my templates.

I checked that the official implementation does the same, and it seems that you aim to have similar output. I hope it isn't too much of a stretch to ask for this, but can we leave the order of the fields as defined in the templates?

[bruno-delfino1995]

I tried submitting the PR only to later realize that there are no guarantees over the order of the keys in the this_entries HashMap. Not even serde_json maintains the shape of the initial JSON - it orders the fields also.

use serde_json::Value;

fn main() {
	let data = r#"
	{
		"name": "John Doe",
		"age": 43,
		"phones": [
			"+44 1234567",
			"+44 2345678"
		]
	}"#;

	// Parse the string of data into serde_json::Value.
	let v: Value = serde_json::from_str(data).unwrap();

	let s: String = serde_json::to_string(&v).unwrap();

	println!("{}", s)
}

I'll elaborate on a better design for kct. Sorry for even bothering you with this question. I'm still discovering Rust and remembering practices from college days when I worked directly with data structures. If you happen to have any idea, I'll be more than pleased to hear it and learn from you.

[CertainLach]

By jsonnet spec - fields in manifest should be ordered by alphanumeric

Also, json itself doesn't guarantee field order, per RFC 7159

An object is an unordered collection of zero or more name/value
pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array.

So you shouldn't rely on fields order :D

For kubernetes manifest purpose you should probally implement toposort for applying some objects before dependents (I.e Namespaces before anything / CRDs before custom objects / custom ordering mechanisms) instead of relying on user to provide correct order. Kubernetes objects mostly have stateless interaction anyway, so there shouldn't be cornercases anyway

[CertainLach]

Released this feature as experimental in https://github.com/CertainLach/jrsonnet/releases/tag/v0.5.0-pre1-test
Lets move all additional discussions to google/jsonnet#903, as this i can't stabilize this in only mine implementation, it also should be implemented somewhere else