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