Good work here, thanks Merlijn. My instinct is that, if we are changing
behaviour, then the option probably needs to be mandatory so that affected
tool chains actually break in a predictable way, rather than in an obscure
"huh, what's going on here".
So, I'm in agreement with Cory's proposal.
>
> * Drop the "builds" portion of the output directory (that was mainly to
> distinguish it from the series portion).
>
We still need to distinguish the charms from `deps` and possibly from
`layers` and `interfaces`.
This is my $JUJU_REPOSITORY:
├── charms
│ ├── builds
│ ├── deps
│ ├──
I am also +1 to the effort (thank you, Merlijn!)
My first instinct would be to keep mycharm/builds as the default output
dir, as that matches the behavior of other tools (like Python's dist
tools). I see the arguments against it, though; it's probably better to
either do the "right" thing and
I am +1 on this effort.
Lets drop dead code paths for juju 1.x and push forward with Juju 2.x
standards.
Constantly dancing the dance of convention over configuration feels like
we've lost sight of simplification and making things simpler is always
welcome in my book.
/ my two cents
All the
Started on https://github.com/juju/charm-tools/pull/320, I'd like to bring
this discussion to the list.
The output directory for charm build can vary in seemingly unpredictable
ways depending on how it is called, the environment, and the charm's
metadata.yaml contents. This is due to historical
That's good to know. Let me try out Andrew's instructions.
On 05/10/2017 07:59 AM, John Meinel wrote:
Also, while agents can be built for CentOS we don't support
Controllers on CentOS at this point. So bootstrap I believe only
supports Ubuntu.
John
=:->
On May 10, 2017 11:44, "Andrew
Also, while agents can be built for CentOS we don't support Controllers on
CentOS at this point. So bootstrap I believe only supports Ubuntu.
John
=:->
On May 10, 2017 11:44, "Andrew Wilkins"
wrote:
> On Wed, May 10, 2017 at 3:08 PM fengxia
On Wed, May 10, 2017 at 3:08 PM fengxia wrote:
> I have followed dev instruction and can build Juju binaries for Ubuntu.
> The dev machine is also Ubuntu.
>
> $ go install -v github.com/juju/juju/…
>
> Using the same binaries will not however bootstrap with "--config
>
I have followed dev instruction and can build Juju binaries for Ubuntu.
The dev machine is also Ubuntu.
$go install -v github.com/juju/juju/…
Using the same binaries will not however bootstrap with "--config
default-series=centos", nor "add-machine --series centos". Both failed
at "no tools