oyd
/
minio
6
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2416 Commits
1 Branch
0 Tags
89 MiB
Tag: Branch: Tree: 9b29af8bbe
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '9b29af8bbe'
${ noResults }
minio/vendor/vendor.json

147 lines
4.4 KiB
Raw Normal View History Unescape

Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
{
"comment": "",
Migrate to golang1.5 release with GO15VENDOREXPERIMENT=1 enabled
9 years ago
"ignore": "",
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
"package": [
logrus logger
9 years ago
{
Migrate to new govendor
9 years ago
"path": "github.com/Sirupsen/logrus",
logrus logger
9 years ago
"revision": "418b41d23a1bf978c06faea5313ba194650ac088",
"revisionTime": "2015-09-08T20:46:18Z"
},
jwt: Add JWT support for minio server. Please read JWT.md before using this feature.
9 years ago
{
"path": "github.com/dgrijalva/jwt-go",
"revision": "afef698c326bfd906b11659432544e5aae441d44",
"revisionTime": "2015-12-30T10:00:00-08:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
{
Migrate to new govendor
9 years ago
"path": "github.com/dustin/go-humanize",
Migrate this project to minio micro services code
9 years ago
"revision": "c20a8bde38c8f5ba06f6600edf473705c96829d1",
"revisionTime": "2015-08-24T01:38:10-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
UI: vendorize github.com/elazarl/go-bindata-assetfs which is needed by ui-assets.go
9 years ago
{
"path": "github.com/elazarl/go-bindata-assetfs",
ui-assets: Integrate UI assets.
9 years ago
"revision": "57eb5e1fc594ad4b0b1dbea7b286d299e0cb43c2",
"revisionTime": "2015-12-24T06:54:52+02:00"
UI: vendorize github.com/elazarl/go-bindata-assetfs which is needed by ui-assets.go
9 years ago
},
Add WebUI assetfs initial version
9 years ago
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/fatih/color",
"revision": "76d423163af754ff6423d2d9be0057fbf03c57c2",
"revisionTime": "2015-08-24T00:44:34+03:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/gorilla/context",
"revision": "1c83b3eabd45b6d76072b66b746c20815fb2872d",
"revisionTime": "2015-08-19T22:12:45-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/gorilla/mux",
"revision": "ee1815431e497d3850809578c93ab6705f1a19f7",
"revisionTime": "2015-08-19T22:15:06-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
Bring in the list APIs implemented by Bala <bala@minio.io>
9 years ago
{
"path": "github.com/gorilla/rpc/v2",
"revision": "64e20900b8aa38bb0771dec71ba3bcc2b07fc8ec",
"revisionTime": "2015-11-05T07:45:51+08:00"
},
{
"path": "github.com/gorilla/rpc/v2/json",
"revision": "64e20900b8aa38bb0771dec71ba3bcc2b07fc8ec",
"revisionTime": "2015-11-05T07:45:51+08:00"
},
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
9 years ago
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/mattn/go-isatty",
"revision": "7fcbc72f853b92b5720db4a6b8482be612daef24",
"revisionTime": "2015-08-14T09:26:29+09:00"
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
9 years ago
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/cli",
cli: vendorize to new CLI package updates. - Fix a new line issue for minioHelpTemplate. - Fixes #974
9 years ago
"revision": "c4a07c7b68db77ccd119183fb1d01dd5972434ab",
"revisionTime": "2015-11-18T20:00:48-08:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
Bring in the list APIs implemented by Bala <bala@minio.io>
9 years ago
{
"path": "github.com/minio/minio-go",
getObject: Add support for special response headers. Supports now response-content-type, response-content-disposition, response-cache-control, response-expires.
9 years ago
"revision": "280f16a52008d3ebba1bd64398b9b082e6738386",
"revisionTime": "2016-02-07T03:45:25-08:00"
Bring in the list APIs implemented by Bala <bala@minio.io>
9 years ago
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/minio-xl/pkg/atomic",
build: Handle builds on env where CGO_ENABLED=0 Fixes #1033
9 years ago
"revision": "69c47f638917ab1cb9e24649c84ac38e6f1891b8",
"revisionTime": "2016-01-14T18:12:05-08:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/minio-xl/pkg/cpu",
Fix portability issues for arm on raspberry pi
9 years ago
"revision": "a5fc6d2430ba2ebcab31b938ab02a42bac85dc2e",
"revisionTime": "2015-10-20T11:16:42-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/minio-xl/pkg/crypto/sha256",
build: Handle builds on env where CGO_ENABLED=0 Fixes #1033
9 years ago
"revision": "69c47f638917ab1cb9e24649c84ac38e6f1891b8",
"revisionTime": "2016-01-14T18:12:05-08:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/minio-xl/pkg/crypto/sha512",
build: Handle builds on env where CGO_ENABLED=0 Fixes #1033
9 years ago
"revision": "69c47f638917ab1cb9e24649c84ac38e6f1891b8",
"revisionTime": "2016-01-14T18:12:05-08:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
9 years ago
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/minio-xl/pkg/minhttp",
Fix portability issues for arm on raspberry pi
9 years ago
"revision": "a5fc6d2430ba2ebcab31b938ab02a42bac85dc2e",
"revisionTime": "2015-10-20T11:16:42-07:00"
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
9 years ago
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/minio-xl/pkg/probe",
Update new changes in probe and add setAppInfo
9 years ago
"revision": "a7b8623fd546965505f18172717393f5de4139a2",
"revisionTime": "2015-10-25T03:03:43-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
},
A better way to print prettified json syntax error msg
9 years ago
{
Migrate this project to minio micro services code
9 years ago
"path": "github.com/minio/minio-xl/pkg/quick",
build: Handle builds on env where CGO_ENABLED=0 Fixes #1033
9 years ago
"revision": "69c47f638917ab1cb9e24649c84ac38e6f1891b8",
"revisionTime": "2016-01-14T18:12:05-08:00"
A better way to print prettified json syntax error msg
9 years ago
},
Enable controller to have CORS
9 years ago
{
Migrate to new govendor
9 years ago
"path": "github.com/rs/cors",
Enable controller to have CORS
9 years ago
"revision": "eb527c8097e0f19a3ff7b253a3fe70545070f420",
"revisionTime": "2015-08-29T22:34:20-07:00"
},
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
9 years ago
{
Migrate to new govendor
9 years ago
"path": "github.com/shiena/ansicolor",
First time mode for controller - Upon first time invocation ``minio controller`` would create access keys and secret id - Upon request passing 'keys' arg ``minio controller`` would provide the keys - Add colorized notification
9 years ago
"revision": "a5e2b567a4dd6cc74545b8a4f27c9d63b9e7735b",
"revisionTime": "2015-07-19T16:15:31+09:00"
},
jwt: Add JWT support for minio server. Please read JWT.md before using this feature.
9 years ago
{
"path": "golang.org/x/crypto/bcrypt",
"revision": "7b85b097bf7527677d54d3220065e966a0e3b613",
"revisionTime": "2015-11-30T17:07:01-05:00"
},
{
"path": "golang.org/x/crypto/blowfish",
"revision": "7b85b097bf7527677d54d3220065e966a0e3b613",
"revisionTime": "2015-11-30T17:07:01-05:00"
},
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
{
Migrate to new govendor
9 years ago
"path": "gopkg.in/check.v1",
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
"revision": "11d3bc7aa68e238947792f30573146a3231fc0f1",
"revisionTime": "2015-07-29T10:04:31+02:00"
Add new logging connectors
9 years ago
},
{
"path": "gopkg.in/mgo.v2",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
},
{
"path": "gopkg.in/mgo.v2/bson",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
},
{
"path": "gopkg.in/mgo.v2/internal/sasl",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
},
{
"path": "gopkg.in/mgo.v2/internal/scram",
"revision": "f402e3a216db333ae6b3ba68b9152a34a0bc6984",
"revisionTime": "2015-10-05T19:07:38-07:00"
Migrate to govendor to avoid limitations of godep - over the course of a project history every maintainer needs to update its dependency packages, the problem essentially with godep is manipulating GOPATH - this manipulation leads to static objects created at different locations which end up conflicting with the overall functionality of golang. This also leads to broken builds. There is no easier way out of this other than asking developers to do 'godep restore' all the time. Which perhaps as a practice doesn't sound like a clean solution. On the other hand 'godep restore' has its own set of problems. - govendor is a right tool but a stop gap tool until we wait for golangs official 1.5 version which fixes this vendoring issue once and for all. - govendor provides consistency in terms of how import paths should be handled unlike manipulation GOPATH. This has advantages - no more compiled objects being referenced in GOPATH and build time GOPATH manging which leads to conflicts. - proper import paths referencing the exact package a project is dependent on. govendor is simple and provides the minimal necessary tooling to achieve this. For now this is the right solution.
10 years ago
}
]
Migrate to new govendor
9 years ago
}