Increasing the size of VERSION in tabular status output

Tue Sep 20 18:24:41 UTC 2016

That would help for every platform and give users a way to configure the
output for their own platform/need.
I live with hi-res screen and would love to be able to customize it as Jay
pointed.

Fabrice.

On Tue, Sep 20, 2016 at 4:09 PM, Jay Wren <jay.wren at canonical.com> wrote:

> 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/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/20160920/107a921e/attachment.html>