This repository has been archived by the owner. It is now read-only.

juju2 2.0-beta13 (devel) #47

Merged
merged 10 commits into from Jul 26, 2016

Conversation

Projects
None yet
4 participants
Contributor

tomck commented Jun 24, 2016

Per discussion in homebrew/homebrew-core#2369, creating separate juju2 formula in --devel only mode. No --head option due to a mismatch of directory structure between github and launchpad.

tomck referenced this pull request in Homebrew/homebrew-core Jul 1, 2016

@UniqMartin UniqMartin changed the title from Create juju2.rb to juju2 2.0-beta10 (devel) Jul 1, 2016

Sorry for the delay! I have a lot on my plate recently and I don't normally look into this tap …

I think this formula is installing binaries that will create a conflict if juju is also installed. Don't know what is more appropriate, but you would need to either rename the binaries or add a conflicts_with line to the formula. cc @sinzui for a second opinion.

Contributor

tomck commented Jul 1, 2016

Is there a way to rename the bin during bin.install, like the target: feature in Casks?

There is a plan to describe a way to have both versions installed concurrently, but either by naming the binary juju2 or using conflicts_with we can resolve that presently.

If it were up to me, it would all be under juju and the suggestion would be to run brew info juju and then use brew switch juju <version>.

Is there a way to rename the bin during bin.install, like the target: feature in Casks?

Yes, you can do something like (maybe better to have that on two separate lines in this case):

bin.install "juju" => "juju2", "juju-metadata" => "juju2-metadata"

If it were up to me, it would all be under juju and the suggestion would be to run brew info juju and then use brew switch juju <version>.

I'm afraid that's not possible as Homebrew has only very limited support for concurrently installing multiple versions of a formula. It's also not really supported. With the core juju formula and this juju2 formula these are going to be two completely independent formulae and thus they won't be able to share a common rack (Cellar/<formula> directory).

Contributor

DomT4 commented Jul 2, 2016

Are the go build steps fetching anything externally, or is juju a completely external-dependencies free project?

@tomck tomck changed the title from juju2 2.0-beta10 (devel) to juju2 2.0-beta11 (devel) Jul 2, 2016

Contributor

tomck commented Jul 2, 2016

@DomT4 I'm not completely sure, there are dependencies: https://github.com/juju/juju/blob/master/Makefile#L20

Contributor

tomck commented Jul 3, 2016

I set up a completely fresh Yosemite install in Virtualbox and installed Brew and then juju2 via this pull request. There were no issues.

sinzui commented Jul 4, 2016

Sorry, I have been traveling.

The dependencies in the makefile are for developers and unit tests. The juju release tarfile has all dependencies vendored into the fat tarfile.

The juju qa team creates the release tarfile and verifies it can be unpacked built on Linux, Windows, and OSX is a few steps:
export GOPATH="$UNPACKED_TARFILE_PATH"
go install github.com/juju/juju/cmd/...

The juju and juju-metadata binaries are all that is needed.

I agree we want to rename these binaries so that they can co-exist with juju 1.x, but there are some side-effect to consider. Juju search the "juju-*" to discover plugins, and the plugins are hardcoded to call "juju". "juju2-metadata" breaks because juju cannot find it and it finds wrong juju. So renameing to "juju2" and "juju-metadata2" allows the command "juju2 metadata" to work.

sinzui commented Jul 14, 2016

I think this formula is good to merge once the binaries are renamed:
bin.install "juju" => "juju2", "juju-metadata" => "juju-metadata2"

Is there anything else needed?

So renameing to "juju2" and "juju-metadata2" allows the command "juju2 metadata" to work.

@sinzui My first impression when reading this was: How would that work? Wouldn't be juju2 metadata still searching for juju-metadata and execute that one if found? juju-metadata2 would be there but stay unused. Or I'm I missing something? (Sorry, I haven't really looked at the juju code, so I'm mostly speculating here.)

Other than that, I think once @tomck incorporates your suggestions, this should be good to go.

Contributor

tomck commented Jul 18, 2016

As far as I can tell it works with the renaming, I don't know what juju-metadata actually does. Build of new commit successful.

@tomck tomck changed the title from juju2 2.0-beta11 (devel) to juju2 2.0-beta12 (devel) Jul 18, 2016

sinzui commented Jul 18, 2016

@UniqMartin ouch, you are right. Renaming the plugin to juju-metadata2 means "juju2 metadata2" is the command to create image and agent streams. Running "juju2 metadata" will use the juju 1 client to create streams. The streams are compatible at this time. There are no plans to change streams and what can changed is limited since the format must be backward compatible with juju 1.18.

This sounds a bit like this could be confusing or problematic in the future and I'm now a bit hesitant to accept the rename as the ideal solution. But of course that's just my outside view from someone who's not using the software.

Would making this formula keg-only maybe be a better solution for the name conflict. That way the binaries wouldn't be linked to /usr/local/bin (for a default Homebrew installation), but if a user wanted to use the binaries from this formula instead of a possibly also installed juju from homebrew/core, they could prefix /usr/local/opt/juju2/bin to their PATH. This way both formulae could be installed in parallel without creating a name conflict. And if someone was really only interested in juju2, they could still symlink those binaries to /usr/local/bin with brew link --force juju2 (though that's not normally something I would recommend).

Does this sound like an acceptable alternative or maybe even a better solution to renaming?

Contributor

tomck commented Jul 18, 2016

Because of the ease of removing and installing bottled software (for the future when it leaves beta), I would just suggest using conflicts.

As mentioned elsewhere, juju and juju2 environments aren't compatible with each other at the moment, and who knows when that'll change? Since most likely people aren't going to be maintaining both, there's no need to bend over backwards to permit a simultaneous install.

I think adding a conflicts_with to this formula instead of doing the rename or taking the keg-only route also sounds like a reasonable solution to me. I'm now getting the impression that the rename is the least desirable solution; I'm equally happy with the other two options.

@tomck tomck changed the title from juju2 2.0-beta12 (devel) to juju2 2.0-beta13 (devel) Jul 24, 2016

Contributor

tomck commented Jul 25, 2016

So, conflicts_with is setup, and it's testing, can this get approved?

@UniqMartin UniqMartin merged commit 85be919 into Homebrew:master Jul 26, 2016

1 check passed

default Build finished.
Details

Sorry, I hadn't noticed that you pushed changes. Thanks for your patience while we worked out the best way to go about adding this formula. That's much appreciated!

Merged in 85be919. Thank you for this contribution to Homebrew, @tomck! 🎉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.