Increasing the size of VERSION in tabular status output

[Jay Wren]

With an accepted minimum value, it seems like $COLUMNS or `stty size` could
be used for variable width status output based on the current terminal
window.

Does the interest in this thread warrant that complexity?

On Mon, Sep 19, 2016 at 10:21 PM, Rick Harding <rick.harding at canonical.com>
wrote:

> 15 seems a bit large. James, it'd be interesting to get a screenshot of a
> full openstack with the messages/etc in place to see how it's sizing up in
> a large complex deploy utilizing the feature fully when rc1 cuts with the
> change.
>
> Thanks
>
> On Mon, Sep 19, 2016 at 7:23 PM Tim Penhey <tim.penhey at canonical.com>
> wrote:
>
>> Yesterday we changed the limit to 15 from 7.
>>
>> Tim
>>
>> On 20/09/16 04:41, Rick Harding wrote:
>> > The primary trouble is that we really want to enforce a limit so that
>> > there's room for the arbitrary text at the end of the same line. I think
>> > we could try 10. I do think we need that hard cutoff. If you need to see
>> > the full value going to the json/yaml format output should display the
>> > full value.
>> >
>> > Thanks for the feedback. As it's new it's great to see folks trying it
>> > and bringing up the issues that get hit.
>> >
>> > Rick
>> >
>> > On Mon, Sep 19, 2016 at 12:04 PM John Meinel <john at arbash-meinel.com
>> > <mailto:john at arbash-meinel.com>> wrote:
>> >
>> >     I'm not sure if the unicode ellipsis would cause table alignment
>> >     issues depending on your terminal and font. We could consider it as
>> >     it does give quite a few characters back. The longest I can come up
>> >     with that doesn't feel just gratuitous is 15
>> >     10.10.10alpha10
>> >     But that might be going to far. I do believe the goal was to funnel
>> >     people to not giving "postgresql-9.8.0-ia32-icc" sort of version
>> >     strings. But it should be useful. 10 characters does seem pretty
>> >     good and doesn't cause us to wrap too often.
>> >     1.2.3beta4
>> >     Fits in 10, but anything that has 2 digits anywhere would end up
>> >     wrapping. It feels a bit odd to force people into 1.2.3b4 though it
>> >     does convey the same information it makes you use a string that may
>> >     not match the actual upstream nomenclature.
>> >
>> >     I guess I could be convinced up to 15 characters but 11 might be an
>> >     alternate if we really want people to share the line width but still
>> >     allow matching upstream version strings.
>> >
>> >     John
>> >     =:->
>> >
>> >
>> >     On Sep 19, 2016 19:13, "Gregory Lutostanski"
>> >     <gregory.lutostanski at canonical.com
>> >     <mailto:gregory.lutostanski at canonical.com>> wrote:
>> >
>> >         Perhaps also using the utf-8 ellipsis (…) would save some
>> >         characters as well.
>> >
>> >         --Greg
>> >
>> >         On Mon, Sep 19, 2016 at 10:09 AM, James Page
>> >         <james.page at ubuntu.com <mailto:james.page at ubuntu.com>> wrote:
>> >
>> >             Hi All
>> >
>> >             We've been experimenting with the new
>> >             application-version-set feature in Juju 2.0 in the OpenStack
>> >             charms team; it provides a much needed way for a charm to
>> >             indicate which version of an OpenStack component is deployed
>> >             at any given point in time.
>> >
>> >             We've come up with an approach that either use the upstream
>> >             version of the principle component being deployed, falling
>> >             back to the codename for an OpenStack release - for
>> >             deployment from source or prior to the packages being
>> >             installed for example.
>> >
>> >             However, we're finding that 7 chars is a bit limiting in the
>> >             default tabular status output - for example:
>> >
>> >               9.0.0~b3 (truncates to 9.0....)
>> >               icehouse (truncates to iceh...)
>> >
>> >             Could this field be expandable on demand? I think our
>> >             longest example would currently be:
>> >
>> >               13.0.0~rc1 (10 chars)
>> >
>> >             Cheers
>> >
>> >             James
>> >
>> >             --
>> >             Juju mailing list
>> >             Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>> >             Modify settings or unsubscribe at:
>> >             https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>> >
>> >
>> >         --
>> >         Juju mailing list
>> >         Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>> >         Modify settings or unsubscribe at:
>> >         https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>> >     --
>> >     Juju mailing list
>> >     Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>> >     Modify settings or unsubscribe at:
>> >     https://lists.ubuntu.com/mailman/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/20160920/5f5bdcc2/attachment.html>