Follow-up to #69
I had a situation where caddy/v2 v2.4.6 was in my go.mod and a replace
on it to use local caddy repo.
When I ran `xcaddy run` to test a caddy module, it failed to run because
the replace included the version v2.4.6, even though somehow the buildenv
go.mod had v2.6.1 (the latest), and the replace directive specified
@v2.4.6 only, so the replacement didn't happen.
I don't think versions in the replacement source/origin are
really that useful for xcaddy.
If experience proves this wrong, we can figure out a better solution.
Add environment variable
XCADDY_GO_BUILD_FLAGS
to override default build arguments from environment (#102).
To support flags with variable arguments Unix-style quoting is supported.
* fix: do not use only hardcoded "go"
* fixed comments and added env to readme
* move GetGo to an internal package
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* Parse JSON output of 'go list'
It's more robust in this way
* Handle all possible replacements properly for runDev()
1. Handle all possible replacements properly for runDev()
Replacement targets are not always paths.
Reference:
https://pkg.go.dev/cmd/go/internal/list#pkg-variables
2. Parse replacement info from 'go list -m -json all'
It's more robust in this way
* Test the 'go list -m -json all' parsing logic
* Call 'go list' command only once
`go list -m -json all` contains all informations we need so we don't
need extra `go list -m -json` call.
* main_windows_test.go: Make tests for Windows
* Support Go 1.16
* Use struct instead of map[string]interface{}
* extract and unexport the `module` struct
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
