Can we break BPM into a submodule with properly vendored dependencies? about bpm-release

[xoebus]

We were just about to make changes to the configuration package today which would have caused a breaking change. I don't think we're ready to expose these as a stable interface yet. I'd like to propose that if we do this that we do it as one of the final steps before 1.0.

👍 on switching to dep as an incremental step inside our own release

👎 (at the moment) of declaring parts of this as part of the public interface

[cppforlife]

I really like the idea of being able to use dep. I think it would be worth exploring whether there's a viable way to do that within a bosh release, allowing is to sidestep the need for a submodule.

we use dep in bosh-dns-release (https://github.com/cloudfoundry/bosh-dns-release/tree/master/src/bosh-dns). no problem afaik.

[xoebus]

We have switched to dep in the latest release (you shouldn't notice any difference). I hope we can extract the main code repository (which should be trivial now) closer to 1.0.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/153565798

The labels on this github issue will be updated when the story is started.

[loewenstein]

• BPM as a tool never needs to be built outside of a BOSH release.

At least the definition of bpm.yml could be interesting outside a BOSH release if someone would want to schedule BPM defined jobs on a different scheduler.

[aramprice]

I really like the idea of being able to use dep. I think it would be worth exploring whether there's a viable way to do that within a bosh release, allowing is to sidestep the need for a submodule.

This is a pattern many other teams use but having code split across submodules is a tax on productivity, except perhaps where that code is shared between many projects.

[jfmyers9]

Even if we use dep while keeping it in the same repository, the golang code for bpm is very hard to import into other projects. This is because bpm-release is a GOPATH and currently bpm imports itself as a top-level import. This would be fundamentally incompatible with how users would have to import our project i.e. import "github.com/cloudfoundry-incubator/bpm-release/src/bpm". I think no matter where we move bpm on the bpm-release GOPATH this is still an issue due to the fact that golang's importing scheme is so closely tied to version control.

As said this may not be a supported use case, but as @loewenstein pointed out, there are use cases such as people importing bpm for accessing it's configuration struct declarations.

[aramprice]

That makes sense. I was kicking around an idea that we might be able to satisfy both the bosh-release directory layout, as well as the golang directory layout with some clever hack.

Seems like we should just bite the bullet and spin out a submodule for the bpm go code.

[jfmyers9]

I'm closing this as I don't see a pressing need to solve this.

If there are consumers that want to consume bpm as a dependency, feel free to comment / open a new issue to address this.