[gentoo-catalyst] standardizing output

[gentoo-catalyst] standardizing output

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

how do people feel about killing off the use of "print" everywhere and
moving to the standard logging module ?  biggest advantages in my mind:
- we get much easier control over where the output goes (file/stdout/...)
- we force people to select a level (info/warning/error)
- we get standardized output
- we can more easily control the output (debug/verbose/etc...)
- we can include module/func/line info transparently in debug modes
- we can exit transparently on fatal/critical messages (rather than using
  die/exit/etc... directly)
- we can colorize warnings/errors transparently
- we get py3 compat for free (all current print usage is py2-only)
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-catalyst] standardizing output

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

On Thu, 8 Oct 2015 20:38:25 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> how do people feel about killing off the use of "print" everywhere and
> moving to the standard logging module ?  biggest advantages in my
> mind:
> - we get much easier control over where the output goes
> (file/stdout/...)
> - we force people to select a level (info/warning/error)
> - we get standardized output
> - we can more easily control the output (debug/verbose/etc...)
> - we can include module/func/line info transparently in debug modes
> - we can exit transparently on fatal/critical messages (rather than
> using die/exit/etc... directly)
> - we can colorize warnings/errors transparently
> - we get py3 compat for free (all current print usage is py2-only)
> -mike


It's been on our wish list for several years.  So go for it!

That'll be one less thing holding up p3 compatibility.

I've added some extra print statements in there doing the re-write, but
there was just too much in there that needed fixing.

One thing that is needed more than that still is:

There are still some hard coded paths.  I believe they are only in the
bash support scripts.  I should have all of the python side changed
over.

All exported variables from python to bash are prefixed with clst_ and
dashes and slashes are replaced with "_" if they are in the variable
name.

We are not able to relocate the main gentoo tree until those are fixed.

It was how I got started re-writing catalyst in the first place.  Then
on the python side paths were hard coded EVERYWHERE and used as both a
variable name and value. 
-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-catalyst] standardizing output

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On 08 Oct 2015 18:24, Brian Dolbec wrote:
> On Thu, 8 Oct 2015 20:38:25 -0400 Mike Frysinger wrote:
> > how do people feel about killing off the use of "print" everywhere and
> > moving to the standard logging module ?  biggest advantages in my
> > mind:
> > - we get much easier control over where the output goes
> > (file/stdout/...)
> > - we force people to select a level (info/warning/error)
> > - we get standardized output
> > - we can more easily control the output (debug/verbose/etc...)
> > - we can include module/func/line info transparently in debug modes
> > - we can exit transparently on fatal/critical messages (rather than
> > using die/exit/etc... directly)
> > - we can colorize warnings/errors transparently
> > - we get py3 compat for free (all current print usage is py2-only)
> 
> It's been on our wish list for several years.  So go for it!

done!

> That'll be one less thing holding up p3 compatibility.
> 
> I've added some extra print statements in there doing the re-write, but
> there was just too much in there that needed fixing.

i have noticed that DeComp calls print() and that's bad juju -- modules
should never call print().

if you do want to expose details like that in a module, you should use
the logging module and tie it to a specific logger.  something like:
	logger = logging.getLogger('DeComp')
	logger.setLevel(logging.CRITICAL)
and then DeComp would only ever call logger.xxx to log output.

if people want to get logging details from DeComp, then they'd do:
	import DeComp
	DeComp.logger.setLevel(logging.DEBUG)
assuming you put the logger into __init__.py of course.  i have no opinion
on how you want to structure that logic.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-catalyst] standardizing output

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On Fri, 9 Oct 2015 02:04:10 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On 08 Oct 2015 18:24, Brian Dolbec wrote:
> > On Thu, 8 Oct 2015 20:38:25 -0400 Mike Frysinger wrote:
> > > how do people feel about killing off the use of "print"
> > > everywhere and moving to the standard logging module ?  biggest
> > > advantages in my mind:
> > > - we get much easier control over where the output goes
> > > (file/stdout/...)
> > > - we force people to select a level (info/warning/error)
> > > - we get standardized output
> > > - we can more easily control the output (debug/verbose/etc...)
> > > - we can include module/func/line info transparently in debug
> > > modes
> > > - we can exit transparently on fatal/critical messages (rather
> > > than using die/exit/etc... directly)
> > > - we can colorize warnings/errors transparently
> > > - we get py3 compat for free (all current print usage is py2-only)
> > 
> > It's been on our wish list for several years.  So go for it!
> 
> done!
> 
> > That'll be one less thing holding up p3 compatibility.
> > 
> > I've added some extra print statements in there doing the re-write,
> > but there was just too much in there that needed fixing.
> 
> i have noticed that DeComp calls print() and that's bad juju --
> modules should never call print().
> 
> if you do want to expose details like that in a module, you should use
> the logging module and tie it to a specific logger.  something like:
> 	logger = logging.getLogger('DeComp')
> 	logger.setLevel(logging.CRITICAL)
> and then DeComp would only ever call logger.xxx to log output.
> 
> if people want to get logging details from DeComp, then they'd do:
> 	import DeComp
> 	DeComp.logger.setLevel(logging.DEBUG)
> assuming you put the logger into __init__.py of course.  i have no
> opinion on how you want to structure that logic.
> -mike

Yeah, I had every intention for it to use logging, I just needed
catalyst to get to using it. So catalyst would provide a logger for
it.  I didn't have any intention for DeComp to create it's own.  I's
just a small module that will live in other apps.

I've just made the API consumer apps provide a logging or similar
suitable module.

I'll convert it over tomorrow.

I'm pleased it won't have it's first release using the print().
They were really just for debugging mostly.  There are a few for errors.

I'll have a look at the other patches in the morning.


-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-catalyst] standardizing output

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On 09 Oct 2015 08:26, Brian Dolbec wrote:
> On Fri, 9 Oct 2015 02:04:10 -0400 Mike Frysinger wrote:
> > i have noticed that DeComp calls print() and that's bad juju --
> > modules should never call print().
> > 
> > if you do want to expose details like that in a module, you should use
> > the logging module and tie it to a specific logger.  something like:
> > 	logger = logging.getLogger('DeComp')
> > 	logger.setLevel(logging.CRITICAL)
> > and then DeComp would only ever call logger.xxx to log output.
> > 
> > if people want to get logging details from DeComp, then they'd do:
> > 	import DeComp
> > 	DeComp.logger.setLevel(logging.DEBUG)
> > assuming you put the logger into __init__.py of course.  i have no
> > opinion on how you want to structure that logic.
> 
> Yeah, I had every intention for it to use logging, I just needed
> catalyst to get to using it. So catalyst would provide a logger for
> it.  I didn't have any intention for DeComp to create it's own.  I's
> just a small module that will live in other apps.

if you call any logging function, you're picking a logger.  even if you
just call logging.log(...), you're implicitly picking the root logger.
the advantage of DeComp creating its own logger is that people don't
have to filter out messages from it.  so while we might want catalyst
to run in verbose mode, i don't think we want modules it pulls in like
DeComp also cluttering up the output.  if we did actually want messages
from DeComp, we can configure the logger it's using to have a higher
level.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]