Normalizing output dir for charm build
Simon Kollberg
simon.kollberg at elastisys.com
Thu May 11 15:01:03 UTC 2017
+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 <cory.johns at canonical.com> 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 <adam.israel at 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.johns at canonical.com>
>> wrote:
>>
>>> Yes, that's what I'm proposing.
>>>
>>> On Thu, May 11, 2017 at 4:47 AM, Merlijn Sebrechts <
>>> merlijn.sebrechts at 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.johns at 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.sebrechts at 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.johns at 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 at lists.ubuntu.com
>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>>> an/listinfo/juju
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170511/4ded1c75/attachment.html>
More information about the Juju
mailing list