+1!
While you're at it; I think it could be wise to namespace everything with
Juju. For example $JUJU_LAYER_PATH and ~/.cache/juju/charm-build/deps or
something similar. I think it would make everything more coherent and also
eliminate the possibility of naming collisions.
This could of course be
Adam,
I think the name "charms" is up to the user, it's just whatever they have
set $JUJU_REPOSITORY to. It just so happens that Merlijn sets his to
JUJU_REPOSITORY=~/charms (or similar).
Previously, the build charm would end up in
{$JUJU_REPOSITORY,$PWD}/{builds,trusty,xenial,...}/$charm_name.
To confirm: Builds will be replaced by a charms directory, and deps moved
to ~/.cache/charm-build. If so, I'm +1 to that.
On Thu, May 11, 2017 at 9:28 AM, Cory Johns
wrote:
> Yes, that's what I'm proposing.
>
> On Thu, May 11, 2017 at 4:47 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> w
Yes, that's what I'm proposing.
On Thu, May 11, 2017 at 4:47 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:
> It seems like deps should go under ~/.cache/charm-build/
>
>
> +1
>
> Now, to be clear, the structure you propose is something like the
> following?
>
>
> ├── charms#
>
> It seems like deps should go under ~/.cache/charm-build/
+1
Now, to be clear, the structure you propose is something like the following?
├── charms# $JUJU_REPOSITORY
│ ├── my-charm
│ ├── ...
├── interfaces# $INTERFACE_PATH
│ ├── ...
├── layers# $LAYER_PATH
│ ├──
There are separate env vars for layers and interfaces, and there should
probably be CLI args as well. Perhaps instead of being required like the
output dir, if they're not provided they just aren't used.
It seems like deps should go under ~/.cache/charm-build/
On Wed, May 10, 2017 at 3:36 PM, Me
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.
Ch
>
> * 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
│ ├── in
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 outp
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 be
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 r
11 matches
Mail list logo