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
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:
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’
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 somepackage release strategy?
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 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:
Indefinite version control for somepackage dependency prior distribution.
somepackage is the large package nightmare that some experienced gophers feared of.
somepackage is likely an outdated package?! (depending on the above question 1).
It’s a dev-ops careful issue since the project was already distributed.
somepackage is a critical dependency (many projects depend on it).