Discussion: Stop using Python?

[krancour]

This goes above and beyond #102

As @duglin has pointed out (tangentially) in #97, limiting the number of languages contributors need to know seems like laudable goal.

[martinmaly]

While I agree with limiting # of languages is a great goal I do think that role of Python (or a scripting language) is going to need to be filled in this repo by something. There may be bash demi-gods among us but I am not quite sure how I would implement boilerplate in pure Bash, and there is big advantage in not having to implement it in a compiled language (go). Of course, I haven't used go in this manner (for scripting-like needs) so maybe it is a great fit for Go and my argument doesn't hold.

I'd be curious what others' experience has been in situations like this.

[krancour]

fwiw, my personal feelings are that I don't like bash any better than I like python, but I recognize the need for one or the other. You may even be making a strong argument for both. This issue is just a way of opening that discussion. I'll retitle it as a proposal so it's clear that this is open to discussion and isn't actionable yet.

[krancour]

@martinmaly:

I am not quite sure how I would implement boilerplate in pure Bash

Can you summarize what boilerplate is for? More generally, can you summarize what we've got in the /hack directory? It's not really documented. It would be helpful to get a sense for what's in there.

[duglin]

LOL I like the title as a statement :-)

[martinmaly]

@krancour

the boilerplate link I included actually points at the k8s core repository and it was intended to point out that k8s core uses Python. I can't speak to what is in that hack/ directory as I am not familiar with k8s core hacks.

what boilerplate does is to check that files have appropriate license header.

[pmorie]

While I do think we should be careful about adding new languages willy-nilly, we might not be able to escape from python. It is used in a number of places in kubernetes mungescripts, iirc, and I would like to begin directly consuming those scripts instead of copying them (as I did with the boilerplate scripts).

[duglin]

I think boilerplate is a good example to look at because I think it does fall into an "in-between" spot - more than a simple bash script but not beefy enough for a compiled language. However, there is another aspect to it and that's its intended use. A lot of the time when a tool becomes more real than what bash can easily support its often a tool that might be useful in broader contexts, and I think boilerplate is a good example of that. By that I mean, it might actually be useful beyond its initial project. Once that happens, and its often done in conjunction with the tool getting moved into a more easily accessible/generic repo, I think the list of prereqs for its use becomes an issue/factor. If people really do intent for it to be used in multiple spots/projects then what it mandates on those projects should be given scrutiny.

So far this project do not require python - aside from non-critical tools - so my preference is that we not be forced to have a dependency on python just to run a tool. This means I would prefer to be able to download an exe (or sh script) to run it - nothing else. So this comment is really more directed at "boilerplate" than us - unless one of us has the time to rewrite it in something other than python.

[pmorie]

Closing; we put the boilerplate verification into the repo-infra repository.