Proposal: display-name for charm metadata

[Marco Ceppi]

On Sat, Sep 24, 2016 at 11:34 AM Alex Kavanagh <alex.kavanagh at canonical.com>
wrote:

> Why not allow the display of the name to be case sensitive, but all usage
> to be case insensitive?  So name is MySQL, but you can juju deploy mYSqL if
> you really wanted to.
>

I expect display names may also include unicode characters in the future,
for example

Übersoftware

Which would need name to still be defined from a store/unique id
perspective.

As for case insensitive juju deploy command, I'd consider that out of scope
of this proposal.

On Sat, Sep 24, 2016 at 2:50 PM, Marco Ceppi <marco.ceppi at canonical.com>
> wrote:
>
>> Hey everyone,
>>
>> I know we're rocking towards 2.0 but this is a problem I've seen voiced a
>> few times now. To date, the `name` field in charm has always been
>> [a-z-0-9_-] where you can't end with `-#`. This makes sense, simple flat
>> names that are all lowercase make it easy to do `juju deploy wordpress`
>> instead of following branding guidelines of `juju deploy WordPress`.
>>
>> However, a lot of applications have very specific branding guidelines for
>> how their display name should be represented. Just a few for example:
>>
>> - WordPress
>> - NS1
>> - MySQL
>> - PostgreSQL
>>
>> Today, in the charmstore each is rendered as:
>>
>> - Wordpress
>> - Ns1
>> - Mysql
>> - Postgresql
>>
>> Very rarely do the display names in the charm store and the intended
>> branding of application align. I'd like to propose an optional field in the
>> charm metadata, `display-name` which would allow slightly more control over
>> charmstore display:
>>
>> ```
>> name: ns1
>> display-name: NS1
>> ```
>>
>> ```
>> name: mysql
>> display-name: MySQL
>> ```
>>
>> etc. This would lead to the store and other places across the Juju Charms
>> properties which referenced the Application, instead of the deployment
>> instructions, to use the display-name field (see attached).
>>
>> Curious opinions on this, repercussions of adding metadata fields, esp
>> for older versions of Juju, and if this is worth pursing.
>>
>> --
>> Juju mailing list
>> Juju at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160924/45e3708e/attachment.html>