Update languages.yml

[kojix2]

Hi.
This is just a suggestion.

In 2020 pastache was replaced by chevron.
#120

However, chevron development has not necessarily been active since then.

In 2022, pystache's official repository was replaced. This repository is hard to find from a search, but there is a commit from 7 months ago.

defunkt/pystache#192
https://github.com/PennyDreadfulMTG/pystache

Perhaps this is a suitable repository to link to.

I actually do not know much about Python.
If you review it and think it is different, feel free to close it.
Thank you.

[jgonggrijp]

Thanks for bringing this to my attention @kojix2.

I agree that pystache might be more appropriate to list than chevron, but I also feel somewhat reluctant to unlist one implementation in favor of another. The existing practice so far has been to list only one implementation per host language, but I feel this is too limiting.

In other words, I think I want to add back pystache but also keep chevron around. How would you approach listing multiple implementations per language?

[emmabastas]

My two cents:

Pick some relatively objective metric for which implementation should be the one to be listed at mustache.github.com. For instance, if there are two implementations foo and bar in the same language one could ask: (just an example)

1. Which one is most spec compliant?
2. Which one has the most permissive license?

Let's say foo is more spec compliant than bar
You list foo at mustache.github.com.
Then you ask the maintainer of foo to link to bar in their README. Maybe after the first summary section you could have a section like:

Alternative implementations

bar is another mustache implementation in [language]. bar doesn't support lambdas and inheritance. On the other hand it's zero-dependency

Why do I suggest this

• More implementations are discoverable for the user - good for users and for implementation authors
• No need to redesign website - good for maintainer

And it's good practice to link to alternatives from ones own README anyways. So I don't feel like it should be too big of an ask.

Other alternatives

• Pick you metric and list one and only one package on the website. It's scary to do in case someone is hurt that you unlinked their implementation and so on. But at the end of the day it's not a big deal and I doubt someone would get genuinely upset with you. (I think most people tend to be more scared of upsetting people in these situations than is called for. If you feel like an evil dictator you've probably hit the sweet spot of getting things done vs taking other people into consideration)
• Redesign website to somehow allow multiple packages to be listed. Could work, but i feel like that would be a relatively big undertaking, and I think that a user looking for an answer to "which implementation should I pick?" would rather have that question answered in a section in a README and not at mustache.github.com

[jgonggrijp]

Thank you for sharing your thoughts, @emmabastas!

I agree it is generally a good practice to acknowledge the alternatives, and that it is not much too ask from implementers. However, that does a rely a lot on the cooperation of the implementers. If we were to rely on that entirely, I think the likely outcome would be that some do and some don't, with the end result that Mustache users get only partial information.

Honestly, the feelings of the maintainers are not my main concern. It is rather that I want to give users a good overview of the options that are available to them. So in general, I do not want to omit implementations, unless they are explicitly end of life or they have been proven to be malicious or something like that.

I already decided I'm willing to edit the site so that I can give a complete overview of the available implementations. If you were to do that, how would you approach it?

[emmabastas]

I already decided I'm willing to edit the site so that I can give a complete overview of the available implementations. If you were to do that, how would you approach it?

I'm just stating my personal preferences here, which are not guaranteed to be representative of anything :-)
I usually prefer reading about a tool/package/program in the README, preferably a GitHub README. If I find a package on npmjs.com for instance, my instinctual action is always to double-click the link to the repository. I guess it's because the GitHub README format is the one most familiar to me and so feels easiest to parse.

With this preference in mind. I'd suggest that if you're concearned about package authors not doing a good job linking to and faithfully describing alternative implementations, then just create you own implementations.md in this repo, and when there are multiple implementations for one language you'd add a section

[Language]

• foo Complies to v1.4.1+λ of the spec.
• bar Zero-dependency with support for variables and sections (no partials)

and then link to that section in mustache.github.com
If there's only one implementation then continue doing what is done now and link to that project directly.

Again I think this is way less work than changing the website. And someone like me might even prefer it.
If you really wanna change the website than I don't know, designing websites is like difficult IMO. Maybe look at how other specifications websites do it. For instance

• Graphql https://graphql.com/learn/top-graphql-tools/#for-the-backend
• Protobuff https://github.com/protocolbuffers/protobuf/blob/main/docs/third_party.md
• YAML https://yaml.org/

(I personally really like how yaml.org does it, and hate how Graphql and Protobuff does it)

Idk if that helps

[jgonggrijp]

Thanks @emmabastas. I like your suggestion and I might actually do it that way.