On 08/30/2014 01:00 AM, Henrik Lindberg wrote:
> API is really what we define it to be.
> IMO, values should be included.
Agreed. Facter.value() is very generic and unlikely to undergo any
drastic changes soon (I assume). But it really forms the heart of the
API, as far as I'm concerned, and the v
As a bit of a followup to this discussion I've created this pull request:
https://github.com/puppetlabs/facter/pull/777
When fixing support for structured facts I noticed that the current data
type bugginess in facter makes it almost unusable with PuppetDB 2.2. As you
can't use the < or > operator
Lets take is_virtual as an example. That fact, and all the boolean facts,
have been strings since the dawn of time. During the first days of creation
people wrote manifests that went if $is_virtual == 'false' {}.
By now, most if not all, DSL consumers are aware of the 'correct' way to do
this,
Hi,
I don't mind even changing that stuff in .Z releases but I think .Y is more
appropriate indeed. Releasing a new major version of Facter every time a
fact is bug fixed seems madness and not something you should get into.
As long as the release notes are in order I think most people have come
Hi,
I really like the points Eric, Wil and Henrik have brought up. Here're
some more from me.
On 2014-08-29 23:11, Kylo Ginsberg wrote:
[Splitting this out of the original thread which was the Facter 2.2.0
announcement.]
On Thu, Aug 28, 2014 at 2:58 AM, David Schmitt mailto:da...@dasz.at>> w