Go Vendor release and How we used it as Protected package feature
Go 1.7 Introduction to Vendor directory and its use cases
Dependency management has always been a galling issue, As your code base grows it simultaneously increases your dependencies, but soon with new updates among those leads to a troublesome task to distribute those particular dependency variously at local, development and collaborative environment .
Because of this you all might have used for example npm in javascript or godep for golang. All these package manager maintains a separate files to create a list either in form of json or raw text form to create a list of dependencies. Now we will begin with a short introduction to golang’s new feature Vendor Directories.
In Go “vendor” is importable only by code in the directory tree rooted at the parent of “vendor”, and only using an import path that omits the prefix up to and including the vendor element.
If a package or a parent folder of a package contains folder named vendor
it will be searched for dependencies using the vendor
folder as an import path root. While vendor
folders can be nested, in most cases it is not advised or needed. Any package in the vendor
folder will be found before the standard library.
So now you can put all your dependencies in your vendor folder and push the complete folder to the master branch .
How to use it to implement protected modifier Feature
Go only provide features for public and private access modifiers based on the first letter being capital or not for example
type Abc func() // This is Public
type xyz func() //This is Private
Now Look at the following given directory structure .
├── css_test.go
├── main.go
└── example_service
├── service1
├── service2
└──can_only_access_vendor_content.go
├── vendor
└──protected1
├──example1.go
├──protected2
├──example2.go ├──only_accessible_upto_service2.go
├── others
├── utility
├── dal
├── config
In the above given example you can see that service2
has nested vendor directory and thereby all the contents of that directory can only accessed by it. thereby no other package like service1
neither utility, dal, config
can use those protected1
and protected2
packages.
and hence package protected 1 and protected 2 are protected packages and can only be accessed inside parent of vendor package.
Do try this simple example and see the usages mentioned above.
Thanks