Packaging broken about beehive-vendor HOT 7 OPEN

BTW, I've started working on this on my own branch.

I haven't created a PR because I removed the RSS dependency in my fork, and I'm not sure that's the way to go.

The alternative would be to change every reference to go-pkg-rss and go-pkg-xmlx in bee.

from beehive-vendor.

At the time when we started using dep it was actually recommended not to commit the Gopkg.toml and Gopkg.lock files (even though that seems to have changed by now). Also, dep requires a newer Go version than Beehive, so we didn't want to make it a build-time dependency (yet).

Have dependencies in a separate repo, loaded as a submodule

I don't see an issue with using a submodule for vendoring, esp. in the case of Beehive which has tons of dependencies. I really dislike the idea of polluting the main repo with all the vendored sources.

Delete and replace the whole vendor/ dir

I don't think we ever delete or replace the vendor dir. What are you referring to?

You're correct that we need to fix the jteeuwen mess, but since it's still vendored I didn't consider master broken.

I'd suggest committing Gopkg.toml and Gopkg.lock, dropping this repository and the submodule, and adding a dep ensure step to the build process. I'm still opposed to adding all the vendored sources to the main repo, though.

from beehive-vendor.

dep requires a newer Go version than Beehive, so we didn't want to make it a build-time dependency

AFAIK, dep only requires 1.9 if you plan on building it, not using it.

I don't think we ever delete or replace the vendor dir. What are you referring to?

I'm referring to beehive-vendor's README:

3. Delete the vendor folder

since it's still vendored I didn't consider master broken.

If I follow the steps in the README, delete vendor/ and run dep init, I cannot successfully fetch dependencies, since that package has been removed.

I'd suggest committing Gopkg.toml and Gopkg.lock, dropping this repository and the submodule, and adding a dep ensure step to the build process. I'm still opposed to adding all the vendored sources to the main repo, though.

I agree with you that it's unpleasant, but having been bitten by this in the past, I don't trust dep's dependency resolution algorithm to guarantee reproducible builds. For that reason, I now commit vendor/ with the rest of the repo, while I wait for vgo to be ready :)

from beehive-vendor.

Oh, I see! Sorry for the misunderstanding. I thought you still had issues building Beehive itself, which should work fine with go get / git clone checking out the vendor submodule for you automatically.

Updating the beehive-vendor repository currently is a bit problematic indeed, but for what it's worth I've fixed the jteeuwen imports in Beehive itself.

Can't wait for vgo either ;-)

from beehive-vendor.

Are you still open to switching to a Gopkg.toml setup, either with or without committing vendor/ to the main repo, and removing this submodule?

I could open a PR for that.

from beehive-vendor.

Are you still open to switching to a Gopkg.toml setup, either with or without committing vendor/ to the main repo, and removing this submodule?

Absolutely, as mentioned I think we could now commit Gopkg.toml to the main repo and drop the vendor repository. I still would prefer not committing vendor to the main repo, but we can change the build process (Makefile) and support dep directly instead.

That would mean a go get would fetch all dependencies and build a beehive from git master (including all its dependencies), while a make would fetch the dependencies with dep first and then builds a more reproducible build.

I could open a PR for that.

Awesome! Looking forward to it!

from beehive-vendor.

Not including vendor/ will make builds slower though, since every time dependencies will have to be fetched. Also, as mentioned previously, I'm not convinced builds are always reproducible with dep, meaning that bug reports could be hard to debug.

Also, dep will have to be downloaded within Travis, so the .travis.yml file will have to be kept in sync when newer dep versions are releasde.

from beehive-vendor.