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

Improve code format during build, remove code-batch-process #21471

Closed
wants to merge 4 commits into from

Conversation

wxiaoguang
Copy link
Contributor

@wxiaoguang wxiaoguang commented Oct 16, 2022

The code-batch-process was introduce to resolve

Actually, after chore(lint): use golangci-lint to call revive and misspell checker. #18145 , the misspell sub-command is never used, the only sub-command call to code-batch-process is gitea-fmt (the import formatter), no misspell anymore.

This PR removes unused misspell package (update: the misspell package is updated in #21458), introduce a gitea-fmt.sh to do the code format (the Makefile has been changed to depend on POSIX commands heavily, so the bash script should be no problem).


Without code-batch-process, some commands like gofumpt don't have the ability to ignore some specialized files. If the files are made to be ignored by Makefile, then the too-long-command-argument problem comes again.


I kept the old Makefile logic as much as possible, feel free to edit on this PR directly.

@wxiaoguang wxiaoguang changed the title Improve code format during build, remove code-batch-format Improve code format during build, remove code-batch-process Oct 16, 2022
# Conflicts:
#	Makefile
#	build/code-batch-process.go
#	build/codeformat/formatimports.go
@wxiaoguang wxiaoguang mentioned this pull request Oct 16, 2022
@wxiaoguang wxiaoguang added this to the 1.18.0 milestone Oct 17, 2022
@wxiaoguang wxiaoguang added the topic/build PR changes how Gitea is built, i.e. regarding Docker or the Makefile label Oct 17, 2022
@GiteaBot GiteaBot added the lgtm/need 1 This PR needs approval from one additional maintainer to be merged. label Oct 18, 2022
@silverwind
Copy link
Member

Without code-batch-process, some commands like gofumpt don't have the ability to ignore some specialized files. If the files are made to be ignored by Makefile, then the too-long-command-argument problem comes again.

It appears gofumpt can accept directories as arguments, which could vastly reduce the command line length if we pass directories that do not contain any ignored files as-is. Only for directories with files to ignore, we'd need to rely on Make filter-out and friends.

@silverwind
Copy link
Member

I feel like gofumpt should support a -exclude argument on CLI, I opened mvdan/gofumpt#250.

GO_VERSION=$(grep -Eo '^go\s+[0-9]+\.[0-9]+' go.mod | cut -d' ' -f2)

echo "Run gofumpt with Go language version $GO_VERSION ..."
gofumpt -extra -lang "$GO_VERSION" "$1" .
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should use the version specified in the Makefile, not the globally installed one. So you would still need to pass GOFUMPT_PACKAGE to this script.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to assume the the gofump has been installed by line 810 $(GO) install $(GOFUMPT_PACKAGE)

Otherwise the line 810 should be removed.

Feel free to propose changes to this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could still run a different version based on what the user had installed last unless go run is used. These go install lines only ensure that the specific version is present on the system. Execution should always be via go run with the specific version, otherwise you get the version the user had installed last.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some more thinking, I think I would prefer to use pre-installed gofumpt (with correct version)

The reason is: Gitea had better to manage all its dependent binaries with correct version and have them in local cache. Otherwise, if developer's network is not stable or they are offline, the go run will be time wasting for their make fmt work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean with "pre-installed" but relying on the global gofumpt is dangerous. Say for example gitea uses gofumpt 0.3.1 and I work on another project which uses gofumpt 0.4.0 which happens to also install the global. The next time I format gitea, it will be with wrong formatting.

Stuff like that can be solved by just using the explicit local version. npm solved this problem around 5 years ago with npx which prefers a local over a global tool.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean something like you said, "manage all its dependent binaries with correct version and have them in local cache", like ./.../bin/gofumpt-0.x.x

@@ -264,7 +264,7 @@ clean:

.PHONY: fmt
fmt:
GOFUMPT_PACKAGE=$(GOFUMPT_PACKAGE) $(GO) run build/code-batch-process.go gitea-fmt -w '{file-list}'
@GO=$(GO) ./build/gitea-fmt.sh -w
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
@GO=$(GO) ./build/gitea-fmt.sh -w
@GOFUMPT_PACKAGE=$(GOFUMPT_PACKAGE) GO=$(GO) ./build/gitea-fmt.sh -w

GO_VERSION=$(grep -Eo '^go\s+[0-9]+\.[0-9]+' go.mod | cut -d' ' -f2)

echo "Run gofumpt with Go language version $GO_VERSION ..."
gofumpt -extra -lang "$GO_VERSION" "$1" .
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
gofumpt -extra -lang "$GO_VERSION" "$1" .
$GO run "$GOFUMPT_PACKAGE" -extra -lang "$GO_VERSION" "$1" .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More discussions in #21471 (comment)

gofumpt -extra -lang "$GO_VERSION" "$1" .

echo "Run codeformat ..."
$GO run ./build/codeformat.go "$1" .
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will fail if $GO path contains whitespace, but I generally think we shouldn't need this variable in first place and we can just use plain go from PATH.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, if I remember the MAKEFILE syntax correctly, there is one small difference: GO ?= go should allow custom go paths by overriding the env var, and it simply defaults to the Go in your path.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will fail if $GO path contains whitespace, but I generally think we shouldn't need this variable in first place and we can just use plain go from PATH.

Fixed in a new commit.

Ah, if I remember the MAKEFILE syntax correctly, there is one small difference: GO ?= go should allow custom go paths by overriding the env var, and it simply defaults to the Go in your path.

In line 5, GO="${GO:=go}, the Makefile could also pass the GO environment to the script.

build/gitea-fmt.sh Outdated Show resolved Hide resolved
@wxiaoguang wxiaoguang removed this from the 1.18.0 milestone Oct 19, 2022
@silverwind
Copy link
Member

silverwind commented Oct 19, 2022

I think we would be better of also removing build/codeformat.go and make make fmt be a simple invocation of $GOFUMPT_PACKAGE with directory arguments where possible which should reduce the argument length enough to fit within the 8k limit of Windows.

@wxiaoguang
Copy link
Contributor Author

It seems that there is still no clear solution. I will close this PR and defer it to the future.

@wxiaoguang wxiaoguang closed this Oct 30, 2022
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/need 1 This PR needs approval from one additional maintainer to be merged. topic/build PR changes how Gitea is built, i.e. regarding Docker or the Makefile
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants