New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maintainers needed! #30
Comments
I'm interested about |
@wicastchen Yes! I have a blog post that I will be publishing soon about how that works, stay tuned :) |
I'd be interested in maintaining this project for those that will still use it in lieu of |
I recommend pointing this project to an active project written in Go, rather than continue this project. There are too many existing projects. We could do better work if we had more help on fewer dependency projects than less help on many. |
@kardianos The bittersweet truth is that go will soon have vendoring support, and we'll all be out of a job. |
@siddharthist Right now go1.5 has build support under a flag. We still need tools to manage dependencies, show nice user friendly dependency graphs, do conflict resolution when two dependencies import the same package at different revisions. Lots of stuff to do. If you'd like to work on an existing project, there are a number of tasks I know still need to be done. |
@kardianos I'm not opposed to what you're suggesting. I just also dislike abandoning a project when most of the current users' problems are easily fixable. I support pointing to antoher project in the README or something to that effect. |
@siddharthist I understand. For your users, it might be best to provide them a tool that translates what gvp uses to what project X uses. Doing that might be better for them in the long run than trying to limp along. |
I defer to the author @pote. What do you think/want for the long term? |
This is really down to personal opinion. I am not maintaining gvp anymore because I only use it every now and then, I can't point a gvp user to another solution because honestly there is no alternative to gvp that is not intrusive, almost every other tool that overlaps with gvp's use case also forces a lot of things on the users, and most of the ones choosing gvp do so explicitly because of it's simplicity and small scope. I think that if someone is willing to use a tool then it makes sense to maintain it, and based on the number of issues/visits/stars/clones that gvp gets I believe maintaining it is not a waste of time by any means. But of course, this is a very personal decision, the way I see it if somebody wants to maintain the tool there is no good reason not to do it. |
@pote I agree. The simplicity factor is huge here. Most other projects that provide the setting of these env vars additionally support dependency versioning, a la gpm. I think this might be what @kardianos has in mind (e.g. you can't "translate" what gvp does to another project - there's no configuration). GVP really only does one thing and does it well, and I'm happy to maintain it while people want to use it. |
What @kardianos had in mind is a tool that is simple to use and understand Go is simple to use, but complex to implement (concurrent GC is not any @kardianos would like to espouse having many dependency tools is not just a On Sat, Jul 11, 2015 at 9:43 AM Langston Barrett notifications@github.com
|
@kardianos Let me just say that I respect your message, and your work on the language. That said, I'm not sure that we're on the same page with regards to the scope of gvp. It only does one thing. It does not attempt to solve many of the problems you're thinking about (which I think are very important, and should be handled elsewhere). It isn't a dependency tool so much a dependency relocator. All it does is change where dependencies will be installed, nothing else. Or perhaps I misunderstand what you're trying to say? |
@siddharthist I think the general idea that gvp handles is fine. While the vendor folder is an experiment for the next 7 months, it is still fine. However your voice (and others) have been heard. Let's use the standard folder /vendor/. Once that is in the go tool, gvp and go away. It might be nice to notify users of this change and tell them to "mv .godep/src vendor" and set GO15VENDOREXPERIMENT=1 . I suppose that's what I'm saying in concrete terms. |
@kardianos I appreciate your concern, I think that's a great idea. Just to get things straight so we all understand the direction this is going: Right nowWe maintain GVP as is. Change the default folder from .godeps to ./vendor. Work on issues and features. Document the ability for users to work with GO15VENDOREXPERIMENT. In seven monthsWe depreciate GVP, point people to the documentation on vendoring. WhyBecause Go tool's vendoring solves many of the same issues as GVP, but isn't quite ready yet. GVP still has an active user base, and we can and should continue supporting them until vendoring is fully released. Does that sound about right @pote @kardianos? |
Sounds good to me :) Thanks. On Sat, Jul 11, 2015 at 10:24 AM Langston Barrett notifications@github.com
|
Well, I disagree.
That sounds like a tool that is not gvp, and that is perfectly fine, but when someone has an idea for a tool the action to take is not to rewrite an existing, perfectly usable solution into a new thing, it is to write the new thing so users can have a choice about their tooling, maybe you want to be looking into Glide for example, it's way closer to what you envision than gvp or gpm and written by a very smart guy who has gone through a lot of other solutions first (including gpm).
I get what you mean and I used to think like that, but now what I think is exactly the opposite: having competing tools is great for users, it makes them think, it gives them the possibility of disagreeing with the tools they use, it gives them choice and saves them from a homogenous ecosystem. Isn't diversity a good thing? And what is this talk about it being confusing? We're talking about software developers here, our job is to think our way out of confusion, not just stand there dazzled like some sort of Pokemon. Nobody is forced to use gvp, the users do it because they like it, or because they dislike every other possibility even more.
Why? If that is the direction Go is taking then the Go tool will accommodate that use case on its own time, there is no need for gvp to change to accommodate a workflow that it doesn't endorse, if that means users prefer the mainstream solution then that is also perfectly fine, but why would we actively remove a working alternative? We'd be losing the power to make a choice, why? I happen to disagree with the way the Go team thinks about dependencies, gvp (and gpm) are a direct result of that, they didn't follow "standard practice" when they were created (because the standard practice was ridiculous), and there is no need for them to follow standard practice now - because in all honesty it's still pretty ridiculous. So I say again: as long as people use gvp and find it useful then gvp has a right to be maintained for those people, but if new, better or simply different ideas arise then it's perfectly fine to code them up, in the end, people will use whatever makes them happy, and there is not a damn thing wrong with that. |
For context: some of this points have been previously discussed in the gpm issues |
Well, I for one am happy to maintain gvp at least until Go's official vendoring/dependency management is released. At that point, I don't think I'll want to continue work on it, but then we'll be right back where we are (which isn't so bad). |
Hello gvp users!
One thing that is becoming abundantly clear is that gvp isn't getting the love its users deserve, unfortunately I very rarely use it - I have lately gotten used to
.env
files and thesource
command mainly, which solve the Go usecase for me as well as others. So I'm thinking about opening the door to contributors who are actually users and want to help improve it's experience.Right now there are several issues in need of attention, the homebrew version of gvp is outdated and faulty, and I'm sure there are a lot of other things that can be done to improve gvp user's lives, if you're reading this and you'd like to help out please say so in this thread, if you know someone who might be interested send them the link! There is no knowledge requirement, just the drive to make a good tool and the willingness to participate in healthy technical discussion.
This won't be limited to a single person - in fact, a small team would be ideal - and you can expect to pretty much have free rein on the direction gvp takes, naturally I will be involved in discussions early on, if only to make sure the spirit of the tool and the expectations users have are maintained, but my ideal scenario would be to become less involved as time goes by and let anyone with the drive to continue be in charge.
The text was updated successfully, but these errors were encountered: