Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

request: make source builds a first class approach to installation #1006

Closed
kortschak opened this issue Mar 30, 2020 · 3 comments · Fixed by #1032
Closed

request: make source builds a first class approach to installation #1006

kortschak opened this issue Mar 30, 2020 · 3 comments · Fixed by #1032

Comments

@kortschak
Copy link
Contributor

kortschak commented Mar 30, 2020

The issue template is not appropriate for this issue, so I have removed it.

In the README's installation section there is a direction to not install golangci-lint from source. Given the support for reliable builds with Go modules, this seems like an extremely odd approach.

It would be good if there were added support for source install of golang-ci lint.

Addressing the directive's points in the README:

Please, do not install golangci-lint by go get:

  1. go.mod replacement directive doesn't apply. It means you will be using patched version of golangci-lint.
    There are no replace directives in that file, and if there were that would be breaking the rationale for the replace directive.
  2. it's much slower than binary installation
    Surely this is up to the user to decide, being a balance between speed of install and the capacity to audit code that is running on the user's machine. Personally, I do not install from binary on my hardware, though I do allow this for travis builds.
  3. its stability depends on your Go version (e.g. on this compiler Go <= 1.12 bug).
    This can be avoided by only supporting source installs for Go versions greater than 1.13. This could easily be stated as building from source is only supported for currently supported Go releases.
  4. it's not guaranteed to work: e.g. we've encountered a lot of issues with Go modules hashes.
    Has this been reported anywhere?
  5. it allows installation from master branch which can't be considered stable.
    If modules are used correctly, this is not the case.
@lopezator
Copy link
Contributor

Hello @kortschak thank you for you report!

We ❤️ doc contributions, please feel free to open a PR linking to this issue, so we can review it.

Point 1 and Point 4 are probably outdated info (go modules and its usage here has evolved a lot lately) and might not apply anymore.

@kortschak
Copy link
Contributor Author

I would need direction for what you consider to be acceptable documentation. What I would be suggesting here would be:

Go

Go source installations are supported for the two most recent Go releases.

GO111MODULE=on go get github.com/golangci/golangci-lint/cmd/golangci-lint

@ernado
Copy link
Member

ernado commented Apr 21, 2020

Looks reasonable to me, those docs are outdated.
We should also stop using vendor, because it is already a go1.14.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants