Broken govendor/dep.. vendor support

[mieczkowski]

@mediocregopher I appreciate that you target to new modules feature in golang, but imports with /v3/ in path broke support for old GOPATH way (try using govendor/dep - it is not working anymore). Please consider some backward compatibility, because some people are not ready for changing dependencies managment system (and don't want to change library, because radix fits perfectly our needs :-) )

[yerden]

+1. dep is apparently broken.

init failed: unable to solve the dependency graph: Solving failure: No versions of github.com/mediocregopher/radix met constraints:
        3.1.0: Could not introduce github.com/mediocregopher/radix@3.1.0 due to multiple problematic subpackages:
        Subpackage github.com/mediocregopher/radix/v3/resp is missing. (Package is required by github.com/mediocregopher/radix.v3@master.)      Subpackage github.com/mediocregopher/radix/v3/resp/resp2 is missing. (Package is required by github.com/mediocregopher/radix.v3@master.)

[mediocregopher]

#50 already reported this. Unfortunately there's not much I can do at this point, it's too late to change the import paths of the package. It looks like dep has a PR open to fix this here: golang/dep#1963

but the author maybe just had a baby, judging by the comments. I'll leave this issue open, waiting on that one to get closed.

[mieczkowski]

@mediocregopher how about putting resp package into te main package? Problematic imports are gone and we have backwards compability ;-)

[yerden]

@mieczkowski I think, just as @mediocregopher stated, that would break builds for a lot of dependency packages. Hence, that would also break backwards compability.

[mediocregopher]

@mieczkowski the only way that would work is if I copied resp and its sub-package into the main one, I wouldn't be able to move them, which would be a giant pain for me as I'd now have a huge maintenance overhead for however long it takes for dep to get fixed.

Perhaps you could fork radix for now and do whatever needs doing, until that PR goes through? Or you could help contribute to that PR so it can get done faster. From the looks of it all it needs is tests and docs.

[awkejiang]

any updates on this issue ?

[mediocregopher]

As i mentioned here there's not really anything to be done. Once again, someone could try contributing to dep to get that PR through, that would be the most effective fix.

[cep21]

You can support both if you make a /v3 directory and move all the code to that directory. It will support both modules and dep. Will you accept a pull request for this?

[cep21]

I made an example of what it would look like to support dep and modules at the same time as #128 It's just a reference PR to see what it looks like.

Edit: This should also support glide.

[mediocregopher]

Hi @cep21, thanks so much for bringing this up! I'm going to continue the convo here rather than the PR.

I do remember reading that section of the docs a long time ago, I guess it just didn't stick in my brain >_< You brought up the aesthetics of having a top-level v3 directory, but honestly I don't think that's a big deal. I do have a couple of questions about other aspects of the idea first that hopefully you, or someone else, could answer (or if everyone's willing to wait a while I can find out myself, but my backlog is very long).

1. When you say:

Even if you don't merge this to master, making it a branch of github.com/mediocregopher/radix would allow people to reference that branch for at least some version of this repository.

How would that work? If someone is using an older version of go that doesn't support modules, how would that go get know to look in that branch?

2. If someone is currently using the import path github.com/mediocregopher/radix, without using modules, wouldn't this change break their builds? I've already broken people's import paths once for modules, I'm not super keen on doing it again.

3. Is there some fundamental reason why these other package managers can't properly support repos which have been designed to work with modules? Modules are the official "way forward", it seems like properly supporting them would be a top-priority issue for a package manager. [WIP] minimal module awareness golang/dep#1963 has been open for nearly a year now, that blows my mind. I know this isn't your fault, but it just seems like having individual projects bend over backwards to support various dependency managers, all because they refuse, or are too lazy, to support the "correct" way, is a crazy way to do things.

4. You made this statement in the PR:

it seems like the right approach while the Go community is in this transition period between dep and modules.

I would argue that the go community is transitioning from go get to modules. I'm pretty sure dep was always labeled as an experiment, so I'd be very surprised if people using dep outnumber people using plain old go get, but I'd love to see some actual numbers one way or the other. That said, if go get is the majority I would be against breaking their builds in order to fix dep, especially, as I mentioned before, when I've already broken their builds once before.

Sorry to be so nitpicky about this, and I do appreciate the effort you put in to put this plan together.

[cep21]

I would argue that the go community is transitioning from go get to modules.

I don't know any company or major go project that was using go get to manage third party dependencies. This was due to wanting to lock down specific versions of a library and ensure their binaries always built. This usually required a lock file or vendor folder, and some software (dep, glide, etc) was used for this. I do agree it would be bad to do any change that breaks go get and this should not.

That said, if go get is the majority I would be against breaking their builds

Your master branch is broken for old versions of go get, because old versions of go don't understand modules. This change would increase compatibility with go get, rather than decrease it. Versions of go updated to understand modules will continue to work with a /v3/ directory.

How would that work?

Ideally this change would be part of master, however in the branch situation their Gopkg.toml file would look like

[[constraint]]
  name = "github.com/mediocregopher/radix"
  branch = "working_with_dep"

Most other dependency tools would have similar support for a branch statement, the main constraint with most of them is that it has to live at the repository location.

If someone is using an older version of go that doesn't support modules, how would that go get know to look in that branch?

It would not. Just like your current master branch, they would continue to be out of luck.

Is there some fundamental reason why these other package managers can't properly support repos which have been designed to work with modules?

There are a few of them and I haven't looked at them all, but I would guess that modules are a strong departure from major version management (putting the /v3/ in the import path vs the branch name) and this breaks a bunch of assumptions their code has which would have to be unraveled.

If someone is currently using the import path github.com/mediocregopher/radix, without using modules, wouldn't this change break their builds?

Your master branch currently does not work for versions of Go that do not support modules. If this was merged, your master branch should continue to support versions of Go that do understand modules, as well as versions of Go that do not. I 100% understand not wanting to break people's builds.

A path to test this would be to push my PR as git tag v3.3.1 without pushing to master. You could then try switching between v3.3.1 and v3.3.0 and back to v3.3.1 to see if it works without an issue.

[mediocregopher]

I don't know any company or major go project that was using go get to manage third party dependencies.

I've worked for one company which did so. Since most go projects are pretty serious about backwards compatibility and not breaking builds, we never found it super necessary to do otherwise.

Your master branch is broken for old versions of go get, because old versions of go don't understand modules. This change would increase compatibility with go get, rather than decrease it.

radix supports the most recent two go versions. In fact the last 4 will work on the master branch, using the non-v3 import paths. So I don't see how you can say the master branch is broken. My issue is not that I'm trying to support old go version, I'm trying to keep from breaking people's builds. My first question regarding how older versions of go would work with the branch idea was unnecessary, so I apologize for that.

So right now the only two options I see are:

1. Push this PR to master, and break builds. I'm not going to do that.

2. Support a secondary branch.

I'm not opposed to the second option in theory, but in practice I don't want to spend the time supporting it. If you'd like, you could direct your PR against a branch called third-party-dep-mgrs, and as I release changes in master in the future I'll accept more PRs against third-party-dep-mgrs to keep them in sync. I don't think tagging will work in that situation, but hopefully most managers can pin to a git commit.

It's not a perfect solution, but would that be acceptable?

[cep21]

Thank you for the clarifications.

Why do you believe merging this PR will break people's existing builds?