Is it possible to import a module using mercurial with ssh?
I have found very little on using mercurial with go and the little that I found was with http.
The short answer is yes.
The text displayed by go help importpath, or available here, describes how to set import paths so as to imply a particular version control system. Some sites are known in advance:
A few common code hosting sites have special syntax:
[list snipped, but GitHub implies using Git protocol, Launchpad implies Bazaar, and so on]
For code hosted on other servers, import paths may either be qualified with the version control type, or the go tool can dynamically fetch the import path over https/http and discover where the code resides from a <meta> tag in the HTML.
So if you don't have access to or control over this sort of <meta> tag, you should import with an explicitly-specified VCS:
... an import path of the form
repository.vcs/path
specifies the given repository, with or without the .vcs suffix, using the named version control system, and then the path inside that repository.
That is, to tell go get that it must speak Mercurial protocol to host example.com you might use:
import "example.com/me.hg/repo"
or:
import "example.com/me/repo.hg"
where the .hg is what implies the use of Mercurial.
Once you've chosen a specific VCS, things get a little trickier:
When a version control system supports multiple protocols, each is tried in turn when downloading. For example, a Git download tries https://, then git+ssh://.
The source code for the Go VCS importer has the details. Mercurial repository imports try https first, then ssh.
If you can use the <meta> tag, that can provide more detail, so that you can avoid the relatively clumsy .hg in the import path:
If the import path is not a known code hosting site and also lacks a version control qualifier, the go tool attempts to fetch the import over https/http and looks for a <meta> tag in the document's HTML <head>.
If you're implementing the <meta> response to the request page,read all of the rest of this, because this goes on to say:
When using modules, an additional variant of the go-import meta tag is recognized and is preferred over those listing version control systems. That variant uses "mod" as the vcs in the content value, as in:
<meta name="go-import" content="example.org mod https://code.org/moduleproxy">
This tag means to fetch modules with paths beginning with example.org from the module proxy available at the URL https://code.org/moduleproxy. See 'go help goproxy' for details about the proxy protocol.
Related
For example, we can use go get k8s.io/client-go to install the go package but is there a way to figure out the source code URL is actually https://github.com/kubernetes/client-go? Because if I visit k8s.io/client-go directly it shows 404.
How does the go client figure out where the source code is in this example?
Command go: Remote import paths:
Certain import paths also describe how to obtain the source code for the package using a revision control system.
... For code hosted on other servers, import paths may either be qualified with the version control type, or the go tool can dynamically fetch the import path over https/http and discover where the code resides from a <meta> tag in the HTML.
... If the import path is not a known code hosting site and also lacks a version control qualifier, the go tool attempts to fetch the import over https/http and looks for a tag in the document's HTML <head>.
The meta tag has the form:
<meta name="go-import" content="import-prefix vcs repo-root">
The import-prefix is the import path corresponding to the repository root. It must be a prefix or an exact match of the package being fetched with "go get". If it's not an exact match, another http request is made at the prefix to verify the <meta> tags match.
For example in your case the go tool will query https://k8s.io/client-go?go-get=1. Checking it ourselves:
curl https://k8s.io/client-go?go-get=1
Response:
<html><head>
<meta name="go-import"
content="k8s.io/client-go
git https://github.com/kubernetes/client-go">
<meta name="go-source"
content="k8s.io/client-go
https://github.com/kubernetes/client-go
https://github.com/kubernetes/client-go/tree/master{/dir}
https://github.com/kubernetes/client-go/blob/master{/dir}/{file}#L{line}">
</head></html>
As you can see, the response HTML document clearly indicates the code is available at github.com/kubernetes/client-go.
I want to set my go module path to example.com/myrepo instead of github.com/myusername/myrepo such that I am able to import in inside another repository.
for example, if my go.mod looks like this
module example.com/myrepo
go 1.13
how will I make go get example.com/myrepo work?
I am getting the following on go get example.com/myrepo
unrecognized import path "example.com/myrepo" (parse https://example.com/myrepo?go-get=1: no go-import meta tags ())
Given I am the owner of example.com how can I do this?
it is called vanity import paths.
In addition to the common hosting sites (GitHub, Bitbucket, etc) and custom VCS URLs (.git, .hg, etc) known to the go command, this mechanism can be used to point a custom URL to any of the services.
you must be looking for this https://sagikazarmark.hu/blog/vanity-import-paths-in-go/.
Making two different go modules
source.cloud.google.com/me/a
source.cloud.google.com/me/b
With source.cloud.google.com/me/common as a common lib dependency (to share a model)
I'm trying to go get source.cloud.google.com/me/common (even manually wrote it in the go.mod file) but I keep receiving the following error:
package source.cloud.google.com/me/common:
unrecognized import path "source.cloud.google.com/me/common"
(parse https://source.cloud.google.com/me/common?go-get=1: no go-import meta tags ())
I have gcloud set up to be able to use app deploy and create new source repositories. I've tried setting up ssh for google cloud and attempted to use manual credentials. This neither works locally or in the google cloud build service.
I want to do two things:
Be able to go get this dependencsource.cloud.google.com/me/common
Be able to integrate this go get into my App Engine automated build pipeline.
Any help would be appreciated.
Configure repo on https://source.cloud.google.com/
Authorize manual git access https://source.developers.google.com/p/YOUR_PROJECT_ID/r/YOUR_REPO
In this example: https://source.developers.google.com/p/m/r/common
Your common module should go like source.developers.google.com/p/m/r/common.git
Run: go get source.developers.google.com/p/m/r/common.git on the other module
I would try the following steps:
Make sure it has manual git access - You can try a git clone from folder "a" to check if correct git access is in place. Delete it after it gets cloned.
Make sure that you are using HTTPs - looks like you are good in that regards - go1.14 made HTTPs as default for go get's.
Now, coming to the actual problem - looks like your private version control systems isn't sending the required "go-import" meta tag.
For example - refer any github go module, you can see the "go-import" meta tag:
In order to fix it, the VCS server needs to respond with this tag when go get tries to download "common" module
<meta name="go-import" content="source.cloud.google.com/me/common git https:source.cloud.google.com/me/common">
This works:
got get source.developers.google.com/p/YOUR_PROJECT_ID/r/YOUR_REPO.git
I'm just learning how to use VGO and it seems like a very simple problem but I could not find any good example explaining how to solve it.
I have project hosted in a private bitbucket repository. Let's assume the project URL is bitbucket.org/mycompany/myapp
At the root level I have the main.go, which imports from a subpackage. The import looks like this:
import "bitbucket.org/mycompany/myapp/subpackage"
Question 1. After I just added that subpackage I do "vgo get ." because I want to fetch some other libraries, but that fails because it tries also to fetch my subpackage from bitbucket rather than using my local version. Obviously, I have not committed my changes so that fetch fails with "remote: Not Found" error. Do I have to push my changes before I do "vgo get ." ?
Question 2. Assuming I have my subpackage in the repository, but I made a small change something in it. Now I want to verify it it works, do I have always push every single change every time before I do vgo build?
In general, is there a way to tell vgo that if an absolute import path refers to my local repository it should take the files from the filesystem, rather than pulling from the bitbucket.org?
(NOTE: All fake URL's below are shown as https:/ or http:/, with just a single slash.)
I've spent most of the day trying to get TortoiseSVN to work with my bug tracking system using a relative URL for the bugtraq:url parameter. I'm using SSL on the repository with a self-issued certificate. I'm using VisualSVN for the server and client pieces and Versioned.com's "Artifacts" for the bug tracking piece.
Seems like the only way I can make the embedded hyperlink (e.e. %BUGID%) work to fire up the browser is to use an absolute path for bugtraq:url, like this:
https:/my-server/svn/ProjectName/trunk/Bugs/artifacts.html#%BUGID%
I've tried every variation I can think of for relative paths (using "^/bla") without any luck. I'm getting a link showing up in the commit and log dialogs, but when I click on it it's a NOP. Here's what the TortoiseSVN docs say:
==
You can also use relative URLs instead of absolute ones. This is useful when your issue tracker is on the same domain/server as your source repository. In case the domain name ever changes, you don't have to adjust the bugtraq:url property. There are two ways to specify a relative URL:
If it begins with the string ^/ it is assumed to be relative to the repository root. For example, ^/../?do=details&id=%BUGID% will resolve to http:/tortoisesvn.net/?do=details&id=%BUGID% if your repository is located on http:/tortoisesvn.net/svn/trunk/.
A URL beginning with the string / is assumed to be relative to the server's hostname. For example /?do=details&id=%BUGID% will resolve to http:/tortoisesvn.net/?do=details&id=%BUGID% if your repository is located anywhere on http:/tortoisesvn.net.
==
I'm beginning to think that this is a limitation of either: A) using HTTPS on my VisualSVN Server; or B) trying to access a project on the same box as the repository but that's stored separate from the repository.