Golang proposal: cmd/go: Support optional URL archive resource for the go run command

Proposal Details

Go has become popular and widely adopted in various ways, from simple tasks such as generating configuration files for various tools using go template, to running as backend services for frontend apps implemented in Node/React, to replacing sub systems of a complex application implemented in Python...

To facilitate simple integration, testing, and deployment with non Golang projects, an optional single URL argument could be added to the existing go run command:

UsageLine: "go run [build flags] [-exec xprog] [URL] package [arguments...]"

Run compiles and runs the named main Go package,
optionally from an archive resource identified by the given URL.

...

If URL is specified, the scheme must be one of file, http, or https.
Archive format is determined by "Content-Type" header or file extension.
Supported extensions are .tar, .tar.gz, .tgz, and .zip.

The following flags only apply to URL archive resource:

    -header header
        Extra header to include when sending HTTP requests.
        May be used several times in a command line.
        Each header must be of the form 'Header: value'.
    -insecure
        This option skips the verification step and proceed without checking.

...

In addition, this new feature could help in other use cases such as distributing/running demo/tutorial (written in Go or any other languages) hosted at an arbitrary URL, assuming go is already installed on the user's machine.

Comment From: ianlancetaylor

You can already run a version of a main package using go run. For example, go run golang.org/x/perf/cmd/benchstat@latest will run the latest version of the benchstat command.

Comment From: qiangli

true. if I understand correctly, the package naming must conform to the golang convention and the package be served on port 443 (unless some workaround on the goproxy)? this change intends to relax the requirement for the package to be archived and served at arbitrary endpoints including non secure ports to facilitate local development and testing for non golang projects that have dependencies on services implemented in go.

As an example, after a package has been built/packaged and made available at: http://jfrog.example.com:8081/artifactory/dev/latest/my-service.tar, to run it is as simple as: go run http://jfrog.example.com:8081/artifactory/dev/latest/my-service.tar

Comment From: ianlancetaylor

Thanks, but I don't see a reason to add additional complexity to support a different way of doing something that we can already do.