These eclasses handle EGO_PN as synonym for repo path with optionally appended "/...", but this is incorrect: both golang-base.eclass and golang-build.eclass define EGO_PN as "the import path for the go package(s) to build". Moreover, example in golang-vcs.eclass shows usage of multiple import paths in EGO_PN (which is correct and should be supported), but later in code it uses ${EGO_PN%/...} which won't work correctly in this case. Repo may contains a lot of go packages, and sometimes we need to build/install only few of them, like "github.com/user/project/cmd/smallapp" or "github.com/user/project/cmd/...". If we'll have to always use "github.com/user/project/..." then this may result in fetching a lot of unneeded dependencies and building a lot of unneeded packages. To fix these issues we should remove ${EGO_PN%/...} everywhere and add separate variable for "repo" itself. `go get` automatically discover repo url from import path, but this is complicated process which involved downloading from network and I'm not sure it's good idea to do the same while emerging package. So, best way is probably to add one more global variable like EGO_REPO: EGO_REPO="github.com/user/project" EGO_PN="${EGO_REPO}/cmd/one ${EGO_REPO}/cmd/two" and then use ${EGO_REPO} instead of ${EGO_PN%/...} everywhere.
(In reply to Alex Efros from comment #0) > These eclasses handle EGO_PN as synonym for repo path with optionally > appended "/...", but this is incorrect: both golang-base.eclass and > golang-build.eclass define EGO_PN as "the import path for the go package(s) > to build". Moreover, example in golang-vcs.eclass shows usage of multiple > import paths in EGO_PN (which is correct and should be supported), but later > in code it uses ${EGO_PN%/...} which won't work correctly in this case. I have been thinking about this, and I think the best way is going to be to go the other way. EGO_PN should only have one entry which is the import path of the project you are writing the ebuild for If "go get github.com/user/project" installs the project correctly, github.com/user/project is what you should be using for EGO_PN. > Repo may contains a lot of go packages, and sometimes we need to > build/install only few of them, like "github.com/user/project/cmd/smallapp" > or "github.com/user/project/cmd/...". If we'll have to always use > "github.com/user/project/..." then this may result in fetching a lot of > unneeded dependencies and building a lot of unneeded packages. > > To fix these issues we should remove ${EGO_PN%/...} everywhere and add > separate variable for "repo" itself. `go get` automatically discover repo > url from import path, but this is complicated process which involved > downloading from network and I'm not sure it's good idea to do the same > while emerging package. So, best way is probably to add one more global > variable like EGO_REPO: > > EGO_REPO="github.com/user/project" > EGO_PN="${EGO_REPO}/cmd/one ${EGO_REPO}/cmd/two" > > and then use ${EGO_REPO} instead of ${EGO_PN%/...} everywhere. Can you point to an ebuild in the tree that illustrates the issues you are talking about so I can take a look at it? Thanks, William
(In reply to William Hubbs from comment #1) > Can you point to an ebuild in the tree that illustrates the issues you are > talking about so I can take a look at it? https://gpo.zugaina.org/Overlays/powerman/net-analyzer/alertmanager https://gpo.zugaina.org/Overlays/powerman/net-analyzer/process-exporter Even if these packages are not in official tree yet, chances are they'll be there anyway - alertmanager is practically a must-have add-on for net-analyzer/prometheus, which is in official tree.
(In reply to William Hubbs from comment #1) > If "go get github.com/user/project" installs the project correctly, > github.com/user/project is what you should be using for EGO_PN. Well, that's not correct for Go projects in general. There is no rule or even established convention it should work this way. Most Go projects on github document required `go get` command to install that package in README, and often it looks like `go get github.com/user/project/cmd/...` or `go get github.com/user/project` instead of `go get github.com/user/project/...`. Usually this is because of vendor/ directory which contains a lot of projects which have own binaries in cmd/ with own dependencies which shouldn't (actually - must not) be installed at all.
