Has work on Glide ceased?

<p>I&#39;ve just been taking a look at the issues on GitHub to see if other people are experiencing an issue that I am when using Glide, and then realised that the last commit was on the 14th of December last year. I know just over a month doesn&#39;t seem like a long time, but I&#39;d imagine that Glide would be the kind of project with a <em>lot</em> of activity. There are 333 open issues, and 26 open pull requests, but the branch other than master with the most recent change is from 3 months ago.</p> <p>I understand that <code>dep</code> is well on it&#39;s way, but I actually still prefer Glide over <code>dep</code> by far (the command names make more sense IMO, and it doesn&#39;t have some issues that I have with <code>dep</code> like only being able to install one new package at once, and having to use that new package straight away for it to stay there if you add another...).</p> <hr/>**评论：**<br/><br/>femot: <pre><p>From the Glide readme:</p> <blockquote> <p>The Go community now has the dep project to manage dependencies. Please consider trying to migrate from Glide to dep. If there is an issue preventing you from migrating please file an issue with dep so the problem can be corrected. Glide will continue to be supported for some time but is considered to be in a state of support rather than active feature development.</p> </blockquote> <p>So it seems like while development hasn&#39;t stopped officially, it might be a good idea to migrate to <code>dep</code>. At least for projects that are supposed to live longer.</p></pre>SeerUD: <pre><p>Aye, I think that&#39;s what&#39;s going to have to happen. That message has been there for a good while now. I think it will be for the best in the long run anyway.</p></pre>n1ghtm4n: <pre><blockquote> <p>[Glide] command names make more sense IMO</p> </blockquote> <p>The reason it&#39;s <code>dep ensure</code> is <a href="https://golang.github.io/dep/docs/FAQ.html#why-is-it-dep-ensure-instead-of-dep-install">explained in the FAQ</a>.</p> <blockquote> <p>The idea of &#34;ensure&#34; is roughly, &#34;ensure that all my local states - code tree, manifest, lock, and vendor - are in sync with each other.&#34;</p> </blockquote> <p><code>dep</code>&#39;s commands may be a little awkward to learn, but as a dependency tool it is <em>enormously</em> better than Glide.</p> <p>1) <strong>It&#39;s the only tool that flattens the dependency tree</strong>. This is critical because nested <code>vendor/</code> directories cause insidious bugs. Basically, every tool before <code>dep</code> was potentially introducing bugs that were so subtle, the community was largely unaware they existed.</p> <p>2) <strong>It&#39;s much easier to update dependencies</strong>. <code>dep</code> is really smart about finding versions of deps that satisfy both <em>your</em> code and <em>your dependencies&#39;</em> code.</p> <p>For the sake of correctness, please everyone get on the <code>dep</code> train. It will solve problems with your Go projects you didn&#39;t know existed.</p></pre>SeerUD: <pre><p>I agree with your points about why <code>dep</code> is a better tool, but not about the command structure.</p> <p>Their argument is that <code>dep ensure</code> is a command that doesn&#39;t let you end up in a weird temporary state. Why couldn&#39;t something like <code>dep get</code> literally do exactly what <code>dep ensure -add</code> does, and <code>dep update</code> do what <code>dep ensure -update</code> does? It&#39;s just a name. </p> <p>Another problem with this is that they even tell you they break the rules that they themselves have made with flags like <code>-add</code>. If you add a new package that&#39;s not yet used in your code, your &#34;local states - code tree, manifest, lock, and vendor&#34; are now not in sync with each other - temporarily. When I have used package managers in the past, installing a new package would update the lock file, updating packages would also update the lock file. All of that side of things is in sync. The only thing left out is the code, and that&#39;s fine, because if something <em>has</em> changed I actually will need to go change it regardless.</p> <p>For now I&#39;ve just set up some abbreviations in fish to make it shorter to type.</p></pre>n1ghtm4n: <pre><p>Even if the naming is weird, the learning curve is basically these four commands.</p> <pre><code>dep init dep ensure -add dep ensure -update dep prune (going away) </code></pre> <p><code>dep prune</code> will soon be merged into <code>dep ensure</code>, and you can avoid using <code>dep ensure -add</code> by just importing the new package and running <code>dep ensure</code>. So you basically have to know two commands with nonintuitive names.</p> <p>I&#39;m not sure what your objection is to <code>dep ensure -add</code>. It temporarily relaxes the requirement that every vendored package must be imported somewhere. This is a convenience feature, for when you want to vendor a dependency first <em>then</em> use it in code. The manifest, lock file, and vendor are never out of sync.</p></pre>SeerUD: <pre><blockquote> <p>The idea of &#34;ensure&#34; is roughly, &#34;ensure that all my local states - code tree, manifest, lock, and vendor - are in sync with each other.&#34;</p> </blockquote> <p>This is why I have a problem with the naming. This is the reasoning, but then they don&#39;t follow their own reasoning. That&#39;s all. </p> <p>The commands are easy, they&#39;re just unnecessary compared to what they could be. It&#39;s not a big deal by any means, like I said, I have set up some abbreviations anyway so I just end up typing <code>depea</code> which expands to <code>dep ensure -add</code> instead.</p> <p>Naming of commands and flags aside, they also have neglected a different convenience feature; being able to update to a new version of a library that has been refactored to the point where old sub-packages no longer exist. This is a pretty big problem IMO, because if you want to upgrade code, you want to have the new code installed so you can see what you need to do to update it.</p> <p>Right now, it has to be something along the lines of:</p> <ul> <li>Remove folder from vendor folder.</li> <li>Clone repo into vendor folder, or put it on your GOPATH at the right version.</li> <li>Make your code changes.</li> <li>Update dep (and you can&#39;t do this inbetween either).</li> </ul> <p>I&#39;d rather sometimes the tool just trusted me and was like &#34;okay, I know your code won&#39;t compile now because that package you&#39;re currently using isn&#39;t there in the new version, but I trust you know that and I will get out of your way, since you&#39;ve passed some flag to tell me to do that&#34;.</p></pre>earthboundkid: <pre><p>I believe you can do what you want by specifying a version override in Gopkg.toml temporarily, but it’s less clearly documented than it could be. </p></pre>sdboyer: <pre><p>yeah, the &#34;in-between&#34; time, when you&#39;re refactoring to work with a new, significantly changed version of a dependency can definitely be an awkward period.</p> <p>this has come up in the issue queue before, and there are some other approaches you can consider taking while in the transitional phase: <a href="https://github.com/golang/dep/issues/1265#issuecomment-336486323" rel="nofollow">https://github.com/golang/dep/issues/1265#issuecomment-336486323</a>. that issue also includes some discussion of possible future plans.</p></pre>earthboundkid: <pre><p>I was not initially aware that you could add an import line then run <code>dep ensure</code> instead of using <code>-add</code>. I think more people should be aware of this feature. For example, to add multiple things at once, just list them all as <code>_</code> imports, run ensure, then use them in your real code. </p></pre>sdboyer: <pre><p>this is discussed in the new <a href="https://golang.github.io/dep/docs/daily-dep.html#adding-a-new-dependency" rel="nofollow">Daily Dep</a> guide :D</p></pre>sdboyer: <pre><p>tons more, better docs now, too ? <a href="https://golang.github.io/dep/docs/introduction.html" rel="nofollow">https://golang.github.io/dep/docs/introduction.html</a></p></pre>tommeyikya: <pre><p>Could someone just create the golang version of composer? (<a href="https://getcomposer.org/" rel="nofollow">https://getcomposer.org/</a>)</p> <p>I have tried all go package managers and none of them came near, every one of them had a blocker issue for me, like not supporting versioning, suggesting to commit the vendor folder into the app (due to the missing versioning support), terrible or non-existent private repository support or lack of authentication support for that matter etc.</p></pre>SeerUD: <pre><p>Both Glide and Dep do handle all of the things you&#39;ve mentioned there. Even if sometimes a little counter-intuitively (e.g. having to edit a file to add a private repo instead of just being able to run a command for it).</p> <p>Composer is excellent, and I do wish there was a direct 1-1 equivalent in Go. Pretty much the only issue I have left with Go package managers is when you want to update a dependency that has been refactored. The tools that are here now just get in your way, and you have to do really weird stuff to make it work. I&#39;ve mentioned it in more detail elsewhere in this post.</p></pre>justinisrael: <pre><p>I still have an open problem with dep when using it on projects behind a proxy and on a mixture of local gitlab and public projects</p> <p><a href="https://github.com/golang/dep/issues/860" rel="nofollow">https://github.com/golang/dep/issues/860</a></p> <p>This isn&#39;t a problem with glide, so I have to keep using glide for now. </p></pre>sdboyer: <pre><p>FWIW, now that we&#39;ve got a new release out, this is one of the main things i plan to turn my attention to.</p></pre>justinisrael: <pre><p>Awesome! If there is a newer and more specific issue that covers this problem, please link me so I can track it! </p></pre>sdboyer: <pre><p>nope, that&#39;s the one to watch :D</p></pre>