Maintainers needed!

[pote]

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 the source 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.

[wicastchen]

I'm interested about .env and source solution.Any more details?

[pote]

@wicastchen Yes! I have a blog post that I will be publishing soon about how that works, stay tuned :)

[langston-barrett]

I'd be interested in maintaining this project for those that will still use it in lieu of .env and source. I'm just getting started with shell scripting, but I'm a fast learner 😄

[kardianos]

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.

[langston-barrett]

@kardianos The bittersweet truth is that go will soon have vendoring support, and we'll all be out of a job.

[kardianos]

@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.

[langston-barrett]

@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.

[kardianos]

@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.

[langston-barrett]

I defer to the author @pote. What do you think/want for the long term?

[pote]

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.

[langston-barrett]

@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.

[kardianos]

What @kardianos had in mind is a tool that is simple to use and understand
for the end user. It would not touch any env and use the /vendor/ folder.
It would be able to work smoothly for tiny projects. It would work smoothly
for huge projects like kubernetes. It would allow introspection. It would
handle transitive dependencies even when they are added at different times.
It would work on windows as well as Linux and OSX. It would work with the
community rather then going all lone wolf.

Go is simple to use, but complex to implement (concurrent GC is not any
more complex for the user but very complex to make). A vendor tool should
be also simple to use. The implementation should be as complex as the
problem domain.

@kardianos would like to espouse having many dependency tools is not just a
personal preference; having many tools actively confuses new and existing
users and fragments the ecosystem.

On Sat, Jul 11, 2015 at 9:43 AM Langston Barrett notifications@github.com
wrote:

@pote https://github.com/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 https://github.com/kardianos has in mind. GVP really
only does one thing and does it well, and I'm happy to maintain it while
people want to use it.

—
Reply to this email directly or view it on GitHub
#30 (comment).

[langston-barrett]

@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?

[kardianos]

@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.
I'm sorry to bike shed on this topic :/ , Thank you for taking time to discuss though!

[langston-barrett]

@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 now

We 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 months

We depreciate GVP, point people to the documentation on vendoring.

Why

Because 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?

[kardianos]

Sounds good to me :) Thanks.

On Sat, Jul 11, 2015 at 10:24 AM Langston Barrett notifications@github.com
wrote:

@kardianos https://github.com/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 now

We 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 months

We depreciate GVP, point people to the documentation on vendoring.
Why

Because 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 https://github.com/pote @kardianos
https://github.com/kardianos?

—
Reply to this email directly or view it on GitHub
#30 (comment).

[pote]

Well, I disagree.

What @kardianos had in mind is a tool that is simple to use and understand
for the end user. It would not touch any env and use the /vendor/ folder.
It would be able to work smoothly for tiny projects. It would work smoothly
for huge projects like kubernetes. It would allow introspection. It would
handle transitive dependencies even when they are added at different times.
It would work on windows as well as Linux and OSX

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).

having many tools actively confuses new and existing users and fragments the ecosystem.

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.

Let's use the standard folder /vendor/. Once that is in the go tool, gvp and go away.

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.

[pote]

For context: some of this points have been previously discussed in the gpm issues

[langston-barrett]

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).