Re: Normalizing output dir for charm build

2017-05-11 Thread Simon Kollberg 
+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 done in a different PR if you feel that it's
outside of this scope.

On 11 May 2017 at 16:25, Cory Johns  wrote:

> 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.  The proposal is to always have it
> go to $JUJU_REPOSITORY/$charm_name instead.
>
> Additionally, it was the case previously that the layers, interfaces, and
> deps directories would default to living under $JUJU_REPOSITORY.  The
> proposal is to move deps to always be under ~/.cache/charm-build/deps and
> to not have any default for layers or interfaces, such that if $LAYER_PATH
> or $INTERFACE_PATH are not set, they will simply be ignored.
>
> All of this with the caveat that $JUJU_REPOSITORY, $LAYER_PATH, and
> $INTERFACE_PATH can be provided / overridden on the CLI.
>
> On Thu, May 11, 2017 at 9:34 AM, Adam Israel 
> wrote:
>
>> 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> 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# $JUJU_REPOSITORY
 │   ├── my-charm
 │   ├── ...
 ├── interfaces# $INTERFACE_PATH
 │   ├── ...
 ├── layers# $LAYER_PATH
 │   ├── ...



 2017-05-10 23:39 GMT+02:00 Cory Johns :

> 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, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> * 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
>> │   ├── interfaces
>> │   ├── layers
>>
>>
>> 2017-05-10 20:03 GMT+02:00 Cory Johns :
>>
>>> 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 reasons,
>>> primarily with how Juju 1.x worked and how charm paths worked prior to 
>>> the
>>> advent of multi-series charms.  However, now that 2.x and multi-series
>>> support are standard, I would like to push for simplifying the output
>>> directory, based on Merlijn's PR.
>>>
>>> Specifically, I'd like to push for the following changes:
>>>
>>> * Drop the series portion of the output directory (we recommend
>>> providing the series in the charm's metadata, making it redundant in the
>>> path).
>>> * Drop the "builds" portion of the output directory (that was mainly
>>> to distinguish it from the series portion).
>>> * Drop the current directory as a fallback option for the output
>>> directory (it causes more confusion than it saves).
>>>
>>> Thus, charm build would always require an output directory to be
>>> given either via --output-dir (-o) or via the $JUJU_REPOSITORY 
>>> environment
>>> variable, and would always put the built charm in 
>>> $output_dir/$charm_name
>>>
>>> Obviously, this is not backwards compatible, and may affect
>>> automated build systems, but I think it would be easy to adjust for and
>>> simplify things for everyone concerned.
>>>
>>> Thoughts?  Objections?
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>

Re: Normalizing output dir for charm build

2017-05-11 Thread Cory Johns 
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.  The
proposal is to always have it go to $JUJU_REPOSITORY/$charm_name instead.

Additionally, it was the case previously that the layers, interfaces, and
deps directories would default to living under $JUJU_REPOSITORY.  The
proposal is to move deps to always be under ~/.cache/charm-build/deps and
to not have any default for layers or interfaces, such that if $LAYER_PATH
or $INTERFACE_PATH are not set, they will simply be ignored.

All of this with the caveat that $JUJU_REPOSITORY, $LAYER_PATH, and
$INTERFACE_PATH can be provided / overridden on the CLI.

On Thu, May 11, 2017 at 9:34 AM, Adam Israel 
wrote:

> 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> 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# $JUJU_REPOSITORY
>>> │   ├── my-charm
>>> │   ├── ...
>>> ├── interfaces# $INTERFACE_PATH
>>> │   ├── ...
>>> ├── layers# $LAYER_PATH
>>> │   ├── ...
>>>
>>>
>>>
>>> 2017-05-10 23:39 GMT+02:00 Cory Johns :
>>>
 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, Merlijn Sebrechts <
 merlijn.sebrec...@gmail.com> wrote:

> * 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
> │   ├── interfaces
> │   ├── layers
>
>
> 2017-05-10 20:03 GMT+02:00 Cory Johns :
>
>> 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 reasons,
>> primarily with how Juju 1.x worked and how charm paths worked prior to 
>> the
>> advent of multi-series charms.  However, now that 2.x and multi-series
>> support are standard, I would like to push for simplifying the output
>> directory, based on Merlijn's PR.
>>
>> Specifically, I'd like to push for the following changes:
>>
>> * Drop the series portion of the output directory (we recommend
>> providing the series in the charm's metadata, making it redundant in the
>> path).
>> * Drop the "builds" portion of the output directory (that was mainly
>> to distinguish it from the series portion).
>> * Drop the current directory as a fallback option for the output
>> directory (it causes more confusion than it saves).
>>
>> Thus, charm build would always require an output directory to be
>> given either via --output-dir (-o) or via the $JUJU_REPOSITORY 
>> environment
>> variable, and would always put the built charm in $output_dir/$charm_name
>>
>> Obviously, this is not backwards compatible, and may affect automated
>> build systems, but I think it would be easy to adjust for and simplify
>> things for everyone concerned.
>>
>> Thoughts?  Objections?
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>

>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

2017-05-11 Thread Adam Israel 
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> 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# $JUJU_REPOSITORY
>> │   ├── my-charm
>> │   ├── ...
>> ├── interfaces# $INTERFACE_PATH
>> │   ├── ...
>> ├── layers# $LAYER_PATH
>> │   ├── ...
>>
>>
>>
>> 2017-05-10 23:39 GMT+02:00 Cory Johns :
>>
>>> 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, Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
 * 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
 │   ├── interfaces
 │   ├── layers


 2017-05-10 20:03 GMT+02:00 Cory Johns :

> 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 reasons,
> primarily with how Juju 1.x worked and how charm paths worked prior to the
> advent of multi-series charms.  However, now that 2.x and multi-series
> support are standard, I would like to push for simplifying the output
> directory, based on Merlijn's PR.
>
> Specifically, I'd like to push for the following changes:
>
> * Drop the series portion of the output directory (we recommend
> providing the series in the charm's metadata, making it redundant in the
> path).
> * Drop the "builds" portion of the output directory (that was mainly
> to distinguish it from the series portion).
> * Drop the current directory as a fallback option for the output
> directory (it causes more confusion than it saves).
>
> Thus, charm build would always require an output directory to be given
> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
> variable, and would always put the built charm in $output_dir/$charm_name
>
> Obviously, this is not backwards compatible, and may affect automated
> build systems, but I think it would be easy to adjust for and simplify
> things for everyone concerned.
>
> Thoughts?  Objections?
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
>

>>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

2017-05-11 Thread Cory Johns 
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# $JUJU_REPOSITORY
> │   ├── my-charm
> │   ├── ...
> ├── interfaces# $INTERFACE_PATH
> │   ├── ...
> ├── layers# $LAYER_PATH
> │   ├── ...
>
>
>
> 2017-05-10 23:39 GMT+02:00 Cory Johns :
>
>> 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, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> * 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
>>> │   ├── interfaces
>>> │   ├── layers
>>>
>>>
>>> 2017-05-10 20:03 GMT+02:00 Cory Johns :
>>>
 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 reasons,
 primarily with how Juju 1.x worked and how charm paths worked prior to the
 advent of multi-series charms.  However, now that 2.x and multi-series
 support are standard, I would like to push for simplifying the output
 directory, based on Merlijn's PR.

 Specifically, I'd like to push for the following changes:

 * Drop the series portion of the output directory (we recommend
 providing the series in the charm's metadata, making it redundant in the
 path).
 * Drop the "builds" portion of the output directory (that was mainly to
 distinguish it from the series portion).
 * Drop the current directory as a fallback option for the output
 directory (it causes more confusion than it saves).

 Thus, charm build would always require an output directory to be given
 either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
 variable, and would always put the built charm in $output_dir/$charm_name

 Obviously, this is not backwards compatible, and may affect automated
 build systems, but I think it would be easy to adjust for and simplify
 things for everyone concerned.

 Thoughts?  Objections?

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
 an/listinfo/juju


>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

2017-05-11 Thread Merlijn Sebrechts 
>
> 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
│   ├── ...



2017-05-10 23:39 GMT+02:00 Cory Johns :

> 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, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> * 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
>> │   ├── interfaces
>> │   ├── layers
>>
>>
>> 2017-05-10 20:03 GMT+02:00 Cory Johns :
>>
>>> 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 reasons, primarily with
>>> how Juju 1.x worked and how charm paths worked prior to the advent of
>>> multi-series charms.  However, now that 2.x and multi-series support are
>>> standard, I would like to push for simplifying the output directory, based
>>> on Merlijn's PR.
>>>
>>> Specifically, I'd like to push for the following changes:
>>>
>>> * Drop the series portion of the output directory (we recommend
>>> providing the series in the charm's metadata, making it redundant in the
>>> path).
>>> * Drop the "builds" portion of the output directory (that was mainly to
>>> distinguish it from the series portion).
>>> * Drop the current directory as a fallback option for the output
>>> directory (it causes more confusion than it saves).
>>>
>>> Thus, charm build would always require an output directory to be given
>>> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
>>> variable, and would always put the built charm in $output_dir/$charm_name
>>>
>>> Obviously, this is not backwards compatible, and may affect automated
>>> build systems, but I think it would be easy to adjust for and simplify
>>> things for everyone concerned.
>>>
>>> Thoughts?  Objections?
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

2017-05-10 Thread Alex Kavanagh 
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.

Cheers
Alex.


On Wed, May 10, 2017 at 3:36 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> * 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
> │   ├── interfaces
> │   ├── layers
>
>
> 2017-05-10 20:03 GMT+02:00 Cory Johns :
>
>> 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 reasons, primarily with
>> how Juju 1.x worked and how charm paths worked prior to the advent of
>> multi-series charms.  However, now that 2.x and multi-series support are
>> standard, I would like to push for simplifying the output directory, based
>> on Merlijn's PR.
>>
>> Specifically, I'd like to push for the following changes:
>>
>> * Drop the series portion of the output directory (we recommend providing
>> the series in the charm's metadata, making it redundant in the path).
>> * Drop the "builds" portion of the output directory (that was mainly to
>> distinguish it from the series portion).
>> * Drop the current directory as a fallback option for the output
>> directory (it causes more confusion than it saves).
>>
>> Thus, charm build would always require an output directory to be given
>> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
>> variable, and would always put the built charm in $output_dir/$charm_name
>>
>> Obviously, this is not backwards compatible, and may affect automated
>> build systems, but I think it would be easy to adjust for and simplify
>> things for everyone concerned.
>>
>> Thoughts?  Objections?
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

2017-05-10 Thread Merlijn Sebrechts 
>
> * 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
│   ├── interfaces
│   ├── layers


2017-05-10 20:03 GMT+02:00 Cory Johns :

> 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 reasons, primarily with
> how Juju 1.x worked and how charm paths worked prior to the advent of
> multi-series charms.  However, now that 2.x and multi-series support are
> standard, I would like to push for simplifying the output directory, based
> on Merlijn's PR.
>
> Specifically, I'd like to push for the following changes:
>
> * Drop the series portion of the output directory (we recommend providing
> the series in the charm's metadata, making it redundant in the path).
> * Drop the "builds" portion of the output directory (that was mainly to
> distinguish it from the series portion).
> * Drop the current directory as a fallback option for the output directory
> (it causes more confusion than it saves).
>
> Thus, charm build would always require an output directory to be given
> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
> variable, and would always put the built charm in $output_dir/$charm_name
>
> Obviously, this is not backwards compatible, and may affect automated
> build systems, but I think it would be easy to adjust for and simplify
> things for everyone concerned.
>
> Thoughts?  Objections?
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

2017-05-10 Thread Pete Vander Giessen 
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 output to a local juju repository, or
require the charm author to specify an alternate setup. That gives people a
predictably consistent experience if they do nothing, while preserving
their ability to give themselves a unique experience :-)

~ PeteVG

On Wed, May 10, 2017 at 2:45 PM Charles Butler 
wrote:

> 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 best
>
> On Wed, May 10, 2017 at 1:03 PM Cory Johns 
> wrote:
>
>> 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 reasons, primarily with
>> how Juju 1.x worked and how charm paths worked prior to the advent of
>> multi-series charms.  However, now that 2.x and multi-series support are
>> standard, I would like to push for simplifying the output directory, based
>> on Merlijn's PR.
>>
>> Specifically, I'd like to push for the following changes:
>>
>> * Drop the series portion of the output directory (we recommend providing
>> the series in the charm's metadata, making it redundant in the path).
>> * Drop the "builds" portion of the output directory (that was mainly to
>> distinguish it from the series portion).
>> * Drop the current directory as a fallback option for the output
>> directory (it causes more confusion than it saves).
>>
>> Thus, charm build would always require an output directory to be given
>> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
>> variable, and would always put the built charm in $output_dir/$charm_name
>>
>> Obviously, this is not backwards compatible, and may affect automated
>> build systems, but I think it would be easy to adjust for and simplify
>> things for everyone concerned.
>>
>> Thoughts?  Objections?
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> conjure-up canonical-kubernetes | jujucharms.com
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

2017-05-10 Thread Charles Butler 
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 best

On Wed, May 10, 2017 at 1:03 PM Cory Johns  wrote:

> 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 reasons, primarily with
> how Juju 1.x worked and how charm paths worked prior to the advent of
> multi-series charms.  However, now that 2.x and multi-series support are
> standard, I would like to push for simplifying the output directory, based
> on Merlijn's PR.
>
> Specifically, I'd like to push for the following changes:
>
> * Drop the series portion of the output directory (we recommend providing
> the series in the charm's metadata, making it redundant in the path).
> * Drop the "builds" portion of the output directory (that was mainly to
> distinguish it from the series portion).
> * Drop the current directory as a fallback option for the output directory
> (it causes more confusion than it saves).
>
> Thus, charm build would always require an output directory to be given
> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
> variable, and would always put the built charm in $output_dir/$charm_name
>
> Obviously, this is not backwards compatible, and may affect automated
> build systems, but I think it would be easy to adjust for and simplify
> things for everyone concerned.
>
> Thoughts?  Objections?
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Normalizing output dir for charm build

2017-05-10 Thread Cory Johns 
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 reasons, primarily with
how Juju 1.x worked and how charm paths worked prior to the advent of
multi-series charms.  However, now that 2.x and multi-series support are
standard, I would like to push for simplifying the output directory, based
on Merlijn's PR.

Specifically, I'd like to push for the following changes:

* Drop the series portion of the output directory (we recommend providing
the series in the charm's metadata, making it redundant in the path).
* Drop the "builds" portion of the output directory (that was mainly to
distinguish it from the series portion).
* Drop the current directory as a fallback option for the output directory
(it causes more confusion than it saves).

Thus, charm build would always require an output directory to be given
either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
variable, and would always put the built charm in $output_dir/$charm_name

Obviously, this is not backwards compatible, and may affect automated build
systems, but I think it would be easy to adjust for and simplify things for
everyone concerned.

Thoughts?  Objections?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju