Great - I'll adapt my solution based on this discussion, probably borrowing heavily from is in Puppet. At the very least I can certainly borrow the API and simply add my own semantic symbols to provide scheme support similar to how I've done it now.
I guess the only other question is about code re-use ... shared code is often hard to solve when it comes to the Facter/Puppet relationship. While I'd like to see us implement a similar solution, there is obviously Puppet-isms in that code that wouldn't transfer easily. Not to mention how we deal with such a shared library. I know we had a similar debate over puppetlabs_spec_helper and using subtrees ... but this being part of real code (not rspec) we can run into distro specific library decomposition hassles. At the moment the library is simple so code duplication problems are quite small, but this might grow. Does anyone have any preferences as to how this should be dealt with? I haven't put any thought into it yet myself to be honest. ken. On Wed, Apr 4, 2012 at 10:15 PM, Pieter van de Bruggen <[email protected]> wrote: > > > On Wed, Apr 4, 2012 at 1:58 PM, Ken Barber <[email protected]> wrote: >> >> > Invoking Windows' native color support changes the color of the pen at >> > that >> > particular moment, tightly coupling the colorization time with output >> > time. >> > In Facter, this is less of a big deal, since you're effectively >> > choosing to >> > style content based on its type at output time. In Puppet, especially >> > with >> > the work done on the module tool (and moving forward into Telly), we're >> > seeing a distinct need to decouple those processes. For example, if I >> > want >> > to colorize only version numbers in the module tool's output, a tight >> > coupling means that I have to (in the worst case): >> > >> > * Decompose the output message on version number boundaries >> > * Iterate over those "chunks" of the output >> > * Print each "chunk" with an appropriate color >> > >> > If I decide to start coloring any other part of the output as well (say, >> > module names), the problem gets more expensive. >> > >> > Injecting ANSI escape sequences into the string as a form of markup >> > (inelegant as it is) gives us flexibility -- we could, in that same >> > example, >> > run a quick s///g and have colorized the string appropriately. While we >> > could easily write our own handler to intercept those escapes on Windows >> > and >> > change the pen color at output time, that's exactly what libraries like >> > ansicon and win32console are doing for us. >> >> Okay - I understand the need to store away variables and re-use them >> later and the issues related to when you colorise them so I can see >> your point. >> >> I guess using the color_print methodology does require a prior >> decomposition that literally applies labels to sections of text. But >> this was intentional I assure you. >> >> Of course you could do this in other ways as well, I originally >> experimented with using labels in the string such as: >> >> print "#{t.color(:green)}My green text{#t.color(:reset)}" >> >> My goal here was to avoid having to have people enter the ANSI/SGR >> codes themselves. But this wasn't going to work with the win32api - as >> the method (t.color) was evaluated before the string was processed >> :-). This could still work with win32console using ANSI escape >> characters. >> >> I guess on a similar note to solve the scheme problem one could do >> something like: >> >> print "#{t.color(:strings)}\"foobar\"#{t.color(:reset)}" >> >> Or some such. Then we can still replace these with the correct escape >> codes in a central place - thus still achieving my scheme solution. >> >> ken. > > > I think we're on the same page. The way Puppet::Util::Colors is implemented > is in pursuit of the same goal. While we don't (yet) have semantic class > names, we definitely *don't* want anyone to have to write their own escape > codes. > > include Puppet::Util::Colors > > red_string = colorize :red, "this string is (#{ colorize :blue, 'mostly' > }) red" > puts colorize(:green, "--> #{red_string} <--") > > (When we have fleshed out our color vocabulary, it should be very simple to > add semantic names to this module.) > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
