Sort Properties on Final Netkan Output

[dbent]

The order of properties in the final .ckan output of Netkan is currently dependent on the order in which code is executed by the various transformers. This PR adds a new ITransformer, PropertySortTransformer that is added to the very end of the pipeline.

PropertySortTransformer has an internal list of known properties and will sort the properties in a well defined order (unknown properties are placed just before the x_generated_by property in alphabetical order, with x_ properties always sorting last).

This means the output of Netkan should remain relatively stable with all sorts of changes.

Sort order was chosen based on what I feel is an intuitive reading order when looking at .ckan files, and mirrors the typical order found in handcrafted .ckan files.

[mheguy]

Thanks for changing the order. =)

[techman83]

Just be prepared for a netkan commit deluge when the changes go through!

[dbent]

Just be prepared for a netkan commit deluge when the changes go through!

True story, but then after this future changes will be less likely to produce such mass updates, woo.

[Dazpoet]

Am I reading this correctly that all comments will now be placed at the top (line 2) in the .ckan files? What about examples like this where the comments placement is related to its information?

[mheguy]

Nested comments remain nested (ex. comments in resources or install stay inside).

And yeah I'm misusing the term nested, but you get what I mean.

[Dazpoet]

Ah makes sense :) I'll admit that my codereading skills are <=0 but this looks good to me and might finally make things formatted in similar ways which would make my ocd very happy

[Dazpoet]

Did some testing with some extremely malformed versions of our indexed CommunityResourcePack.netkan file and everything seems to work as it should. Having multiple non-nested versions of the same field in the same file leads to only the one closest to the bottom being listed in the created .ckan. I assumed comments to be the only field where such a thing could possibly be and only found three such cases and one is in a handwritten .ckan which is fixed by KSP-CKAN/CKAN-meta#744

The other two are in CacEye2.netkan and KSIPlacementServices.netkan neither of which should present a problem since the comments are only relevant for the .netkan files either way.

I don't speak code so I'll just trust Travis on that one.

To me the above thing with only keeping the bottom most one of non-nested duplicate fields isn't a showstopper so I'd say this is ready for a merge, however I'll let the clever netkan people know before merging and potentially blowing up ckan-meta 😈

[Dazpoet]

Discussed on irc and the above is not a showstopper so I'm merging this. @techman83 might see a gigantic thing pushed by netkan-bot as an effect if I understand the discussion in this PR correctly.

[techman83]

@Dazpoet hahaha, yep! ALL THE COMMITS!!

[techman83]

And an excerpt from the bot log -> https://gist.github.com/techman83/7cda2f560b4d6cd864b5

[pjf]

@techman83 : It looks like the bot is very committed!