Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
remove sed in a go1.10 and go1.11 compatible way #6567
That makes Go the only immediate tooling dependency.
Like #6564, but keeping go1.10 as the minimum required version.
Note: this doesn't remove
changed the title
remove sed in simultaneously go1.10 and go1.11 compatible way
Apr 10, 2019
@@ Coverage Diff @@ ## master #6567 +/- ## ========================================== - Coverage 41.67% 41.67% -0.01% ========================================== Files 414 414 Lines 55985 55985 ========================================== - Hits 23331 23329 -2 - Misses 29524 29527 +3 + Partials 3130 3129 -1
zeripath left a comment
We shouldn't generate the bindata unless explicitly asked to. I appreciate that almost all of us pass in TAGS="bindata sqlite sqlite_lock_verify" so it seems unnecessary to have to repeatedly specify but there are some very good reasons why you might not want compiled bindata.
Now maybe you could change things so that an empty TAGS leads to generate asking some questions to set TAGS? You'd probably want some way of saving these options too. Of course then you should support nobindata as a build tag.
@zeripath As far as Tags go, I don't think that makes sense for the non-production use case. The goal here is not to utterly replace the Makefile, but rather to make it so that builds "just work" with standard Go tooling - frustration free.
If someone wants to include
(which I would think is intuitive for the type of person who wants to do that)
However, I don't think it should be a hard-stop requirement as it works around the standard "Go way" to do things.
I must have misread the Makefile. I thought that it was already generating bindata all the time, but only including it when the tag was there. I'll take a look into that.
@appleboy Putting constants on the left is a good habit to have. It ensures that you'll never have an accidental assignment where it could be prevented. Go has other checks in place so it's less likely, but bradfitz still does it in some of his code, and it's certainly acceptable Go style. Why do it the other way?
@lunny These are meta packages for build tooling. They don't have any functional code to test, other than what is already tested by virtue of the build succeeding.
The output is non-deterministic as it relies on getting the git version from the repository. It wouldn't make sense to build out a fake repository just to test that the behavior of
The only thing that's "testable" is the order in which the environment variables are read - but that behavior was built to mimic what the make file was already doing - which is for the purpose of the build system.
Technically that could be abstracted out into its own library and then a separate main function could be published as a command... but I think that's overdoing it a bit.
I'm not opposed to adding tests, but I don't think that there is anything to test.
@lunny Just added a test file for testing the priority of the ENV variables, but that's the only thing I think that I can reasonably test here.
I think that after this is merged, someone might consider whether or not the behavior that was written into the Makefile, which is preserved here verbatim, is actually the desired behavior. It seems strange to me, but since it's just build tooling, and it's how it already was, I thought might as well copy it.
Having written tests for it now, however, I question if it really needs to be so complex (and inconsistent).
My guess is that the Makefile was actually incorrect (but happened to not fail from the complexity) and that what was intended was more along the lines of this:
I think that the other stuff regarding
If that's your personal preference I'd be just fine if you went back and changed it to the way you like, but as far as contributions Go I think we should just stick with standard Go code style (which is already quite stringent) and not put additional restrictions on it other than that, except where there's a cost (i.e. bringing in another dependency when an existing dependency already has the same function or a little copying would do).
I think that enforcing typographically and /or lexicographically sorted if statements (
The process is already confusing - the whole autonomous organization thing and not knowing who has "say" or what "matters" - and I really just want to help deliver value (to Windows users in this case) and get a quick return.
I don't mind iterating on things that are objectively important - like fixing functionality that changed, edge cases on different platforms, failing tests, etc. These are all things I expect to spend time on.
When it comes to subjective things, I'd much prefer it if the people with the strongest opinions would take responsibility to the effect of "This is my personal preference, would you mind if I change this after it gets merged in?" rather than having an ambiguous burden on the person doing the patch.
Does that make sense? Do you see value in that approach? Is there something you really value about the current process that might be helpful for me to understand?
@lunny I pulled my test back out because I think it would be better to define what is supposed to be tested, and because it would require adding tooling-specific build tags to existing tests to be tested (and I'm pretty sure that's not what you really want). If it is, I will do it.
@solderjs In my opinion, it is more about consistency rather than personal preference at this point. It was probably a subjective choice of the original authors (like unknown/lunny etc). Typically, I prefer to follow the style of the surrounding code, even if it were not the best in my own taste. Plus, it'd be a good idea to separate the style changes & features/fixes in different PRs. Or if we want to adopt a new style, we should change the whole codebase (or plan for doing it incrementally).
Just my 2 cents.
@typeless (cool name, btw)
I don't see in value in consistency for consistency's sake. If the original authors happened to do something a certain way (i.e. lexicographically sort
Since that's something very local to this specific codebase, and not the Go community at large, and since it literally doesn't matter in terms of readability or code function, why bother? Why add the overhead?
From a pragmatic point of view, it's just one more thing that has to maintained, communicated, etc. If no one actually knows why its done or why it's desirable or preferable, then why canonize it?
In my point of view, consistency in of itself is only valuable when it reduces the need for communication.
And I was about to give an example... but I can't come up with one for Go because all of the things that I would normally choose are already handled by
Anyway, in this case, having localized style increases communication cost and work rather than reduce it.
I believe that local styles are important, but I believe they should be used for the sorts of things that reduce documentation and communication cost. Again, Go pretty much already enforces everything I would normally present as on off-the-cuff example.
By design, Go makes it difficult to have these sort of debates. :) Yay for Go the utilitarian pragmatist Go developers
@appleboy @techknowlogick I've made the requested change, but I would like to continue to have the discussion. I believe like this is an amazing project and my goal is to help make it more accessible to more people and reduce your overhead so that more contributions can make the full loop without any unnecessary friction.