[sos-devel] isatty opinions

[Jesse Jaggars]

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/06/2012 04:27 PM, Jesse Jaggars wrote:
> > 09/06/2012 02:19 PM Bryn M. Reeves wrote:
> >> On 09/05/2012 09:37 PM, Jesse Jaggars wrote:
> >>> So I've been reassigned the following JDR bug:
> >>> https://issues.jboss.org/browse/JBPAPP-9565
> > Yep that's basically it. The community version just ships the .so
> > files that come with jython, but that's not an acceptable option
> > for EAP unfortunately. There was some discussion of making an
> > exception somehow but that fizzled out.
> 
> It might be worth revisiting that; I think there have been similar
> exceptions in the past (we have previously even supported products
> that we had to build natively on Solaris, although not recently
> iirc).
>

I'll probably bring this back up. I'd like to avoid changing code
for such a specific user base.
 
> > Could be, I haven't investigated trying with pure java and then
> > falling back onto os.isatty. That's probably possible, but it
> > promotes ugliness.
> 
> Afaik Java still lacks a native isatty() equivalent (otherwise I
> guess
> Jython would just use that implementation). There's been a bug open
> for about 15 years so I'm not holding my breath for that:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4099017
> 

Figures, scratch that. I'll likely go the route you mentioned previously
and try to skip the isatty calls under jython if it comes down to code
changes.

> > This isn't entirely true, but sosreport is forced into batch mode
> > operation in every case so maybe we could skip the whole thing in
> > this case.
> 
> In Jython generally, sure, but in the scenario we're expecting sos to
> run would we expect a real tty? Either way it's really moot since you
> mentioned that we're always forcing batch mode there.
> 
> > So colored output was removed so the only real benefit is the
> > setting of batch mode in this case. I wonder if defaulting to batch
> > mode would be a miserable idea? Providing we add an --interactive
> > option.
> 
> I'd be very reluctant - this would be a change in behaviour that's
> been around since sysreport. We have a lot of product and training
> docs as well as considerable field knowledge that says that when you
> just run "sosreport" you get an interactive prompt-driven UI.
> 
> We've talked about making some UI changes and I'd still like to carry
> on with that. It's possible this might give us a better avenue for
> doing this but I think forcing batch on a default invocation of
> "sosreport" is likely to be very unpopular with users and support
> engineers.
> 
> >> I would guess that there are quite a few users that run sos
> >> without a tty and expect that to imply batch mode. Without that
> >> check we'll start prompting for stuff and those users current
> >> modes of execution will hang.
> 
> I wouldn't be happy unleashing this as-is (i.e. as a change in
> behaviour of the existing sosreport command - if a user runs
> "sosreport" we want them to get the expected behaviour).
> 

Agree here. And on the long list of things we would like to change, 
this behavior is very low on that list (if it even belongs.)

> > Getting sosreport to work in jython has added some corner-case
> > handling ugliness already, but it'd be nice to cut back on that I
> > think. Might be a good idea to think about separating the UI layer
> > from the actual machinery.
> 
> This is absolutely something that I favour (although I'm concerned by
> some of the recent changes that I see adding interactivity in
> individual modules - we've never had any structured way to handle
> that
> and it's generally something I think we should avoid - for much the
> same reason as RPM avoids interaction during package installation and
> updates).
> 

Makes sense to me. I wasn't aware of any interactive plugins. I'm certainly
not a fan of that idea generally.

> Do we have any reasonable way to determine what needs to be avoided
> in
> the Jython environment? A list of unavailable standard library
> modules
> or functions would be a great help in understanding the implications
> of this.
> 

I'm not sure. Generally though anything that is backed up by c should be avoided.
C-based extensions simply do not work and code that relies on underlying c libraries
requires the jffi binary stuff. The jffi bits wouldn't be a problem if it
weren't for the productization requirements.

At plugin load time, assuming you build your plugin with all imports made at the top
of the file, sosreport will disable your plugin if it can't load all the libraries
you depend upon. This provides a minimal safety net for these situations, but in the
case of the os module, we don't run into linking errors simply by importing os.

> Regards,
> Bryn.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlBIyy4ACgkQ6YSQoMYUY96RUQCgyI+tgYWqLBqyoxjNgzf7loM6
> bWcAoMu2nlhzLRYZhzw91eMlRUkiKtEK
> =BmrO
> -----END PGP SIGNATURE-----
>