Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't install #20

Open
kisinga opened this issue Jul 15, 2019 · 5 comments
Open

Can't install #20

kisinga opened this issue Jul 15, 2019 · 5 comments

Comments

@kisinga
Copy link

kisinga commented Jul 15, 2019

getting the error fatal: repository 'https://github.com/BoseCorp/go-idm-lib/' not found when I run go get github.com/Bose/go-gin-logrus

@Jim-Lambert-Bose
Copy link

we fixed this on Feb 22: eb716ce#diff-37aff102a57d3d7b797f152915a6dc16
in release: v2.0.1
try: go get -u github.com/Bose/go-gin-logrus@v2.0.7

@kisinga
Copy link
Author

kisinga commented Jul 15, 2019

It worked
However, I'll leave the issue open since a direct install causes the error

@Jim-Lambert-Bose
Copy link

happy to hear it worked. I need to investigate how to fix this "direct" install issue.

@Shawn-Silva-Bose
Copy link
Contributor

vgo modules need a bit of extra work when jumping to a major version > 1.

When developers reach v2, semantic import versioning means that a /v2/ is added to the import path at the end of the module root prefix: my/thing/v2/sub/pkg. There are good reasons for this convention, as described in the earlier post, but it is still a departure from existing tools. Realizing this, vgo will not use any v2 or later tag in a source code repository without first checking that it has a go.mod with a module path declaration ending in that major version (for example, module "my/thing/v2"). Vgo uses that declaration as evidence that the author is using semantic import versioning to name packages within that module. This is especially important for multi-package modules, since the import paths within the module must contain the /v2/ element to avoid referring back to the v1 module.

We expect that most developers will prefer to follow the usual “major branch” convention, in which different major versions live in different branches.

vgo-modules

I think the options are:

  1. Make branches for each major version with correct go.mod and imports

    • go.mod (module github.com/Bose/go-gin-logrus/v2)
  2. Move v2 to a subdirectory with its own go.mod in master.

  3. Update go.mod on master and release directly from there, possibly introducing issues for downstream users not utilizing go modules yet. (unintentional package updates)

Releasing modules v2 or higher

@Jim-Lambert-Bose
Copy link

Thanks Shawn. I didn’t realize the implications when I rev’d to v2. I’ll make some decisions next week about this and hopefully choose a way fwd that won’t be too painful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants