project structure: move gps into a dep internal directory

[kardianos]

Right now development is in two places: dep and gps. Also gps has to satisfy two customers: dep and glide.

If it is a goal of dep a) become the standard and b) be developed quickly, I suspect pulling gps into an internal directory for now, allowing the API to change quickly and atomically, would speed up development. It would also put all issues in a single location. Let glide continue to use the gps version where it currently is.

To be clear, I applaud breaking up the tool into an package API and a CLI. That is exactly how govendor is structured. And in time the interna/gps package would be removed from internal to an exposed package.

[sdboyer]

I feel like this has been raised before, but I can't find it in the queue...maybe it was in slack, or something.

glide isn't actually using gps right now - the integration branch that I was working on hasn't moved in months. So the two customers thing isn't really an issue (though the requirements haven't really diverged, either).

It's not totally clear to me that having gps in a separate repository is something that's really an impediment to development. But, my gut reaction to this proposal right now is that it'd slay something I've worked on for a year, so my judgment isn't the clearest.

So: if we really think it would speed up development, then sure, let's do it. Migrating the (open) issues would also definitely be needed, and would be a bit of work - help on that would be great. I'd also rather not put it in an internal directory. It seems like that would just encourage us to muddy the line between the library and the tool. Plus - let's not pretend, here - moving gps into dep directly would kill sdboyer/gps, and I don't want a public interface to go away.

---

EDIT - this comment was really not well-thought through. Obviously, gps has to move into dep sooner or later. That, of course, means some loss of some control for me - but that's kinda the whole idea here. I responded before having really overcome my gut reaction, and I'm sorry.

[kardianos]

@sdboyer Developing golang/dep is a proposal to kill govendor, gvt, etc, many of these have been in development for over a year or more. If the API package is central to dep, then the API package also becomes at least somewhat official. If it is an official API package, we need to be careful not to break API, or carefully version the API.

What I'm proposing is that the API package should be unstable as dep is still pre 1.0 and many features need to be added. As such it should be in an internal directory by definition and by go std definition.

I mean what I'm saying is I don't want to worry about breaking API or versioning if I were to personally contribute. I'm willing to contribute to golang/dep (provided I can make the time), but I don't have the will to contribute to sdboyer/gps at this time, esp when you say you don't want the public interface to go away, I don't want to worry about an existing public interface at this stage.

I suppose I would see if there are others in a similar boat as I'm in.

[sdboyer]

Developing golang/dep is a proposal to kill govendor, gvt, etc, many of these have been in development for over a year or more.

Sure, of course, we're all putting our projects/work on the line here. Sorry, I didn't mean to suggest otherwise - I'm just being honest about my gut reaction to the proposal, and explaining why my judgment about its utility is clouded.

What I'm proposing is that the API package should be unstable as dep is still pre 1.0 and many features need to be added. As such it should be in an internal directory by definition and by go std definition.

We're not adhering to that within the github.com/golang/dep package itself, right now. Which should be fine, because the dogfood we're eating here - at least, prior to merging into the toolchain and becoming subject to different guarantees - is the model this tool enables, not the model as it has been. That is, we (or at least gps) are following semver with pre-1.0.0 releases, which provide no guarantee of API stability. v0.14.0 of gps broke v0.13.0, which broke v0.12.0. Which is to say:

esp when you say you don't want the public interface to go away, I don't want to worry about an existing public interface at this stage.

I'm not worrying about it, and IMO, you needn't be, either. But, yes -

I suppose I would see if there are others in a similar boat as I'm in.

I think it'd be good to get more feedback, too.

[carolynvs]

gps solves an interesting problem and I would hate to see it end up hidden in an internal package that only dep can use.

I'm working on PR right now that crosses the boundary between the two repos. It's a little more work but personally, having them clearly separated reinforced that it's a public interface, so I wasn't tempted to muck about with it willy-nilly.

Just throwing in my 2 cents, that having gps separate hasn't been a burden to this contributor at all.

[kardianos]

(I'm not suggesting gps be internal for all time, just during primary development.) That's just it, we need to be able to muck with it willy-nilly during this period. That's exactly my point.

[sdboyer]

OK, I conferred with other committee members, and they're inclined to move it now, so let's do it. I'll get the remaining PRs finished up, then pull it over.

The big blocker now, then, is migrating the existing issues. I'd really like to avoid doing that by hand, if possible :)

[kardianos]

Issue migration might be assisted with: https://github.com/IQAndreas/github-issues-import or similar.

[sdboyer]

I'm gonna work on making this happen this week

[sdboyer]

OK so, after reading around about licensing, I'm now more confused than when I started.

Does anyone understand what the necessary steps are, license-wise, to moving gps into dep directly? @adg?

[adg]

I've enquired with our open source people, and hope to hear from them soon.