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.hard...@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.pen...@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 <j...@arbash-meinel.com >> > <mailto:j...@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.lutostan...@canonical.com >> > <mailto:gregory.lutostan...@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.p...@ubuntu.com <mailto:james.p...@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@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju >> > >> > >> > >> > -- >> > Juju mailing list >> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju >> > >> > -- >> > Juju mailing list >> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju >> > >> > >> > >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju