+1 for optional 'display-name' field that doesn't have the naming
restrictions of 'name'
-1 for case insensitivity use as part of this work.
Tim
On 25/09/16 05:02, Marco Ceppi wrote:
On Sat, Sep 24, 2016 at 11:34 AM Alex Kavanagh
<alex.kavan...@canonical.com <mailto:alex.kavan...@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.ce...@canonical.com <mailto:marco.ce...@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@lists.ubuntu.com <mailto: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
