Glide: Remove `vendor` directory of this repository

[IndraGunawan]

we can easily install the vendor using glide install and i think good if we ignore the vendor directory from commit.

thanks for advice

[dieselburner]

Just add vendor directory to .gitignore, and you're done.

Please close this.

[krancour]

Just add vendor directory to .gitignore, and you're done.

That is so far from the truth. That will only stop further changes to the vendor directory from being tracked. There are additional steps required to remove the vendor directory from the remote repository (i.e. github).

But much more importantly, there's a question of whether vendor _should_ be removed. I have worked on many projects that deliberately don't include it and many that deliberately do. There are defensible reasons for both. I am certain that the glide team didn't decide to track vendor without weighing the pros and cons of that against the pros and cons of _not_ tracking it.

At any rate, it's not right to so casually dismiss this issue.

[dieselburner]

I totally agree that it's purely project and developer style dependent.

I'm the one that prefers not to keep vendor folder in my repo, and writing a proper glide configuration file helps me with that.

But...

This particular issue, if you look into description, OP does not go into debates what is good and what is bad. For me, either description is poorly written, or issue author is just annoyed by the fact that he sees the vendor folder in git status. Based on that, I'm not sure if we should open yet another useless discussion about project layout, or just provide the non-abusive comment about OP git skills.

[jrick]

If the vendor directory is removed, and you don't already have glide built to populate the directory, how are you going to build glide?

It's a bootstrapping issue. Most projects can get away with not committing the directory, but glide needs to.

[dieselburner]

Ah, sorry... That's should be a long day for me. For some reason I thought that OP is talking about vendor folder of his own project, the description looked weird to me. Now I got the point.

Of course, adding dependency of itself is not a good way to go.

[IndraGunawan]

sorry for bad description of this issue
i mean why this repo has vendor directory?
i think if a repo does not have vendor dir. then glide will create the directory.
the source codes inside vendor directory are 3rd party libraries (from other repo)
so i think the vendor of this repo should not commit to git.

[krancour]

i mean why this repo has vendor directory?
i think if a repo does not have vendor dir. then glide will create the directory.

@IndraGunawan this comment was the explanation for that already:

https://github.com/Masterminds/glide/issues/760#issuecomment-280690477

If vendored code _isn't_ tracked in this project, then you need glide to build glide. That self-referential dependency is an unresolvable chicken and egg problem.

[IndraGunawan]

then why not using last binary version of glide to build new version?

[krancour]

Disclaimer: I've made modest contributions to glide, but I'm not a member of the team. I do think I can shed some more light on your inquiry though.

While what you have suggested above might work, as a general principle, it's probably better not to completely _rely_ on the previous version to build the current one. Glide's own dependencies _are_ managed with glide, but because vendor is tracked, you don't _have to_ have the previous version of glide to build it. It would be _optional_ and only needed if you intend to update the dependencies.

So glide uses glide, but isn't entirely dependent on it. Why is this important?

Requiring the previous version of any given tool to build the current version of that tool complicates things greatly. Imagine all versions of such a tool are enumerated in the order of their release, using cardinal numbers 1..n. To build a version k, where k <= n, you would require version k - 1. To have that would require that you can build k - 1 using k - 2, and build _that_ using k - 3. This regression continues until you need to build version 1, but you can't because there exists no version 0.

Yes... this is a very academic argument, for sure. And while what you have proposed is _possible_, that is due only to the pre-compiled binaries for each official release being readily available. In _general_, however, many projects like to retain the ability to rebuild any version from source only at any time and then my argument applies.

[IndraGunawan]

thanks for your reply and very clear.

the problem about version only affected when creating the first version but now gradle has stable realase.

we can see composer (pm for php) repository theres no vendor directory. i know glide different with composer but i see how glide manage the 3rd party lib similiar with composer.

if this issue so annoying, may i close this issue?

[krancour]

You aren't wrong. And I mean, tbh, I generally do not like including vendor in my own projects. I'm articulating one possible rationale for the decision wrt _this_ project. And that may not even be the rationale that the team actually used when deciding to track vendor. My only point here has been to highlight that the question of tracking vs not tracking vendor is a nuanced one and there isn't necessarily a one size fits all answer. It could be worthy of further discussion, so I wouldn't rush to close this. We should let someone more in touch with the original decision like @technosophos or @mattfarina farina weigh in to explain why they chose this.

[dieselburner]

Btw, another option would be to use git submodules. Has anyone looked into this direction?

[krancour]

Y'all do realize that the proposal to remove vendor or to start using git submodules are both major changes and it seems they're being proposed for what reason? Because of a personal aversion to tracking vendor? Just hang tight and wait for a maintainer to respond to this.

[technosophos]

This repo has a committed vendor/ directory so that go get github.com/Masterminds/glide works in a 100% predictable fashion.