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 <adam.isr...@canonical.com>
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 <cory.jo...@canonical.com>
> 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 <cory.jo...@canonical.com>:
>>>
>>>> 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 <cory.jo...@canonical.com>:
>>>>>
>>>>>> 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

Reply via email to