Using Go without go get – Is it possible?

At home (Ubuntu 18.04) here I can do this:

go get

Alas, at work (Red Hat 7) this fails because because I’m blocked by our proxy server (my work gnu/linux environment is intentionally isolated for security reasons). However, also at work, I can download items from my Windows 10 host.

So… is there some way I can use my ability to download in Windows 10 to get Go packages and in turn copy them to Red Hat host? Thoughts?

Cheers, -Randy
Please note: I posted this on (Diaspora Social Network). If someone answers there I’ll update this topic with the details.

I could only think of downloading the package on Windows and copying it over ssh via scp to your Linux host. You could also use rsync if you are allowed to install WSL or use WSL altogether at this point.

Thanks Luis. By “downloading the package” do you mean run go get on Windows? Or something else? Like clone the package from (or, or other location)? At the moment I don’t have Go installed on Windows. Cheers, -Randy

Oh, I unterstood

I can download items from my Windows 10 host

as you having the go tool installed. In effect the go tool does no different than cloning the repository with the defined VCS and doing some checksum calculation.

I would clone or download the repository and scp to your machine.

I installed the Windows msi for go 1.19. At the command prompt I run:

go get -x

This produces 5 lines of # get

Alas, it ends in a time-out error: “connected host failed to respond.”

Yet if I take the URL and paste into Firefox I see the mod file without delay. Thus it looks like there is a difference between what Firefox does vs go get from the command prompt. I’ll keep pondering.

Cheers, -Randy

In effect the go tool does no different than cloning the repository

Very interesting. When I add -x I can see

go get -x

becomes a series of cd, git clone and git submodule update commands like:

git clone (myhomedir)/go/src/

Cheers, -Randy

Problem solved. Using %xx encoding of special characters in the password expressed in https_proxy variable allowed go get to work from Red Hat 7. Thus my assumption that such access was no longer allowed was wrong. Also learned that go 1.18 (at work) does not leave behind .git dirs like go 1.10 at home. This reflects, I believe, module management landing in go (1.14 and above?). Cheers, -Randy

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.