Go.mod exclude specific packages when 'go mod vendor'


To exclude specific packages when ‘go mod vendor’, I wrote the ‘go.mod’ file like this

module xxx

replace github.com/somepackage => /$GOPATH/pkg/mod/github.com/somepackage@v1.2.3

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

  1. 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.

  2. If I replace the line like this

replace github.com/somepackage => ../../pkg/mod/github.com/somepackage@v1.2.3

The path is not a problem, but ‘…/pkg/mod/github.com/somepackage@v1.2.3/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 = [

Is the somepackage a module or classical GOPATH package?

Basically, 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:

  |        + go.mod
  |        + ...
           + go.mod?
           + ...

or the vendor packages inside myProject.

Then, inside myProject/go.mod, your replace clause would be:

replace github.com/somepackage => ../somePackage

So go will seek out the local directory for github.com/somepackage module.

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.

More info:

  1. replace clause:
  1. 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

  1. the ‘somepackage’ doesn’t have go.mod (it uses ‘dep’)
  2. the size of the ‘somepackage’ is very large
  3. I have to vendor other packages except the ‘somepackage’
  4. ‘somepackage’ has many versions and my code have not to bind a specific version
  5. 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’
  6. I work as a team
  7. I just need the ‘ignored’ directive of the ‘dep’
  8. 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. :grin:

I still need some info about the somepackage.

  1. Is it a sleeping project? (as in missing maintainers)
  2. 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?
  3. Have your team explored the exclude route in go.mod? (Yes, I might sound superbly silly in this case but just to be sure.)

Details about exclude clause: https://github.com/golang/go/wiki/Modules#can-an-additional-gomod-exclude-unnecessary-content-do-modules-have-the-equivalent-of-a-gitignore-file

  1. Have you guys planning to version control the dependencies in the future? (as in, do you guys have something in mind so far)?
  2. What is the current somepackage release strategy?
  3. 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)?
  4. Is there a distribution level sandbox environment to test your already deployed Docker distribution?
  5. Is the license for the somepackage permits 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:

  1. Indefinite version control for somepackage dependency prior distribution.
  2. somepackage is the large package nightmare that some experienced gophers feared of.
  3. somepackage is likely an outdated package?! (depending on the above question 1).
  4. It’s a dev-ops careful issue since the project was already distributed.
  5. somepackage is a critical dependency (many projects depend on it).
1 Like

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