Bundle source paths

[knkski]

@johnsca, @wallyworld: This is what I've got going to solve juju/charm-tools#513, along with https://github.com/knkski/rust-libjuju. Should probably get everyone on board before merging this, so bikeshed away.

[wallyworld]

So is the intent that the processing of the bundle will be such that if there's a built charm at the specified build location, that will be used, else the store version will be pulled?

[johnsca]

I'm not particularly liking having the path to the charm source in the bundle, since it will remain when the bundle is pushed to the store. It is also specific to your environment; for example, my directory structure is ~/juju-charms/{charms,bundles} so your relative paths wouldn't work for me.

We already have charm build environment variables defined for CHARM_BUILD_DIR, CHARM_LAYERS_DIR, and CHARM_INTERFACES_DIR. What do you think about adding CHARM_CHARMS_DIR and having the juju-bundle plugin use those to determine automatically if any of the charms referenced in the bundle can be built and updated? I had already felt like not including that var was something of an oversight, and it would be nice to be able to say charm build foo and just have it work, no matter what directory you currently happen to be in.

I would also prefer using the CHARM_BUILD_DIR var as well, instead of creating a temp dir, since that ensures that the charm is built into the same place that it would be when working with it individually, and things like in-place upgrades are more consistent.

[knkski]

@wallyworld: the intent would be that if there's charm source code at the specified location, it will be built and used

[knkski]

@johnsca: Good point about it remaining in the bundle - juju deploy will ignore the build attribute since it doesn't know about it, but the bundle plugin would currently prefer the local path to the charm store one. I think we could either have it only prefer building charms if it's deploying a local bundle, or add a --build flag, though.

Does having something like source: charm-redis-k8s vs build: ../charm-redis-k8s match up with what you're thinking, and have juju-bundle look at $CHARM_SOURCE_DIR/charm-redis-k8s to find the charm source (bikeshedding that I think CHARM_SOURCE_DIR is a little less vague than CHARM_CHARMS_DIR).

Good call on CHARM_BUILD_DIR, will update that.

[johnsca]

+10 on CHARM_SOURCE_DIR; that's much better. Also +1 to the source: field. I mentioned during the demo the idea of using charm pull-source but then I realized the difficulty of dealing with resources etc. and I don't think it's really worth messing with.

[knkski]

Updated this PR with source: instead of build:, and updated https://github.com/knkski/rust-libjuju to look at CHARM_SOURCE_DIR for the charm sources, and CHARM_BUILD_DIR for the built charms