module xxx replace github.com/somepackage => /$GOPATHfirstname.lastname@example.org
I don’t want to vendor the ‘somepackage’ of any versions.
And I use ‘go mod’ only for vendoring, so the actual local package path does not matter.
It works with go v1.12
But It doesn’t work with go v1.13.x
How to use environment variables ‘$GOPATH’ in the ‘go.mod’?
I can’t replace ‘$GOPAHT’ to the real path. Because I work with my team, and members’ $GOPATHs are not the same.
If I replace the line like this
replace github.com/somepackage => ../../email@example.com
The path is not a problem, but ‘…/firstname.lastname@example.org/go.mod: no such file or directory’ error occurred.
Furthermore, If I want to vendor only some subpackage of the ‘somepackage’, how can I do that?
‘somepackage’ has ‘aa’, ‘aa/cc’ and ‘bb’
‘somepackage/aa’ <- don’t vendor
‘somepackage/aa/cc’ <- do vendor
‘somepackage/bb’ <- don’t vendor
With ‘dep’ I can do that with the ‘Gopkg.toml’ like this
ignored = [ "github.com/somepackage/aa", "github.com/somepackage/bb/*" ]
Is the somepackage a module or classical GOPATH package?
replace clause it aliasing the
github.com/somepackage import keyword to a local directory or another package module. In other word, you can
git clone the
somepackage next to your project, in a file directory like:
root +---myProject | + go.mod | + ... +---somePackage + go.mod? + ...
or the vendor packages inside
replace clause would be:
replace github.com/somepackage => ../somePackage
So go will seek out the local directory for
Also, you do not have to point towards the
$GOPATH/pkg/mod directory manually because that is go module’s working directory. If that’s something you’re looking for, then the replace clause would be:
replace github.com/somepackage/aa/cc => github.com/anotherPackage/aa/cc vX.Y.Z
If all else still fails, you might need to do vendor-module migrations for specific vendor package/subpackage.
- Module and Vendor
@ hollowaykeanho Thank you.
I know the solution already and I have done like you in some projects.
But in this case, I can’t do that for some reason.
I have so many projects using ‘somepackage’ and their directory locations vary widely.
So, that way, I should have many clones of the ‘somepackage’.
If I have to change(or update) the ‘somepackage’, it will be very annoying.
My case is
- the ‘somepackage’ doesn’t have go.mod (it uses ‘dep’)
- the size of the ‘somepackage’ is very large
- I have to vendor other packages except the ‘somepackage’
- ‘somepackage’ has many versions and my code have not to bind a specific version
- I build and execute the project in the docker containers
5-1. each container uses a different image
5-2. each image has ‘somepackage’ in its GOPATH already (their GOPATH are not the same)
5-3. each image uses a different version of the ‘somepackage’
- I work as a team
- I just need the ‘ignored’ directive of the ‘dep’
- some project can’t under ‘GOPATH/src’, so I have to use ‘go mod’
Can you give me some advice?
This is a good news. At least you aren’t alone.
I still need some info about the
- Is it a sleeping project? (as in missing maintainers)
- If maintainers are available, are there any issue raised related to the matter (e.g. porting to go module etc)? If no, IMO, are you able to raise a question to the maintainer about the matter?
- Have your team explored the
go.mod? (Yes, I might sound superbly silly in this case but just to be sure.)
- Have you guys planning to version control the dependencies in the future? (as in, do you guys have something in mind so far)?
- What is the current
- is the sub-packages (e.g.
aa/cc) cross-depends within themselves? If yes, are you able to map them out easily (as in take less than 15 mins)?
- Is there a distribution level sandbox environment to test your already deployed Docker distribution?
- Is the license for the
somepackagepermits forking and editing without copyleft effect? (e.g. MIT, Apache2, …, and not GPL… basically you got the license to do that without forcing you to open your source codes.)
Currently, the list of identified problems are:
- Indefinite version control for
somepackagedependency prior distribution.
somepackageis the large package nightmare that some experienced gophers feared of.
somepackageis likely an outdated package?! (depending on the above question 1).
- It’s a dev-ops careful issue since the project was already distributed.
somepackageis a critical dependency (many projects depend on it).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.