Could clarify if this is about spaces in repository URLs or package paths?

Arguments to go get are package paths. Given a package path, go get finds the repository URL by sending a request to https://example.com/pkg?go-get=1 (for package example.com/pkg), then looking for a go-import meta tag. Remote import paths has more info.

I think spaces in repository URLs are already allowed. I don't know of any reason they should be rejected, so if they're not working, we should fix that.

It sounds like this is more about allowing spaces in package paths though. golang.org/x/mod/module.CheckImportPath describes the current limitations.

CheckImportPath checks that an import path is valid.

A valid import path consists of one or more valid path elements separated by slashes (U+002F). (It must not begin with nor end in a slash.)

A valid path element is a non-empty string made up of ASCII letters, ASCII digits, and limited ASCII punctuation: + - . _ and ~. It must not begin or end with a dot (U+002E), nor contain two dots in a row.

The element prefix up to the first dot must not be a reserved file name on Windows, regardless of case (CON, com1, NuL, and so on).

CheckImportPath may be less restrictive in the future, but see the top-level package documentation for additional information about subtleties of Unicode.

Hi @jayconrod

This is about spaces in the git repo URL, AFAIK. In my example above I forgot to add that I'm using the .git extension.

go get "dev.azure.com/org/Project%20Name/_git/reponame.git" / go get "dev.azure.com/org/Project Name/_git/reponame.git" this is all part of the repo URL, not any sub packages.

$ go get "dev.azure.com/org/Project Name/_git/reponame.git"
go get dev.azure.com/org/Project Name/_git/reponame.git: malformed module path "dev.azure.com/org/Project Name/_git/reponame.git": invalid char ' '

@mbrancato, the argument to go get is a package path, not a URL.

The package path often corresponds to the URL, but they are separate entities. (The .git extension is one mechanism the go tool uses to convert between the two, but it is by no means the only way.)

Given that there are straightforward workarounds (either choose a project name without spaces, or set up a go-import HTTPS server that can resolve a spaceless path to a URL-encoded repo URL), I think the usability benefits of rejecting spaces in package paths still outweigh the flexibility of allowing spaces in package paths.

@mbrancato Your examples reference package paths on the command line. Repository URLs won't appear on the command line or in .go files; they'll only show up in <meta go-import ...> tags, as described in Remove import paths.

As an example of how this is typically set up, consider the module golang.org/x/mod. In order to locate its repository, go get sends a GET request to https://golang.org/x/mod?go-get=1. The server responds with HTML containing the following tag:

<meta name="go-import" content="golang.org/x/mod git https://go.googlesource.com/mod">

From that, go get learns that it should clone the repository https://go.googlesource.com/mod.

I believe spaces are already supported in repository URLs, but if you find that's not the case, please give an example where it's not working.

I'm not convinced spaces should be allowed in module and package paths. Package paths use a limited set of characters for clarity and simplicity. If the underlying repository URL has spaces, that's okay, but the package path will need to be different from the repository URL.