>
>> That's only semantic BS. The primary consumer of facter is puppet code
>> writers. If the meaning of return values of something like sprintf would
>> change, all hell would break loose. Why should it be different for the
>> return value of $operatingsystem ?
>>
>>
>
> Preach it, Brother!
>
>
On Saturday, August 30, 2014 3:10:14 AM UTC-5, David Schmitt wrote:
>
> 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
> 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
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 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
On Fri, Aug 29, 2014 at 2:11 PM, Kylo Ginsberg wrote:
> There are a couple really good issues here, and I'm torn on the answers:
>
> 1) While semver clearly applies to the Facter *API*, I'm not sure if it
> provides guidance on Facter *values*. Yes, on the one hand, I could argue
> that the valu
Maybe worth considering a separate level of semver/facter guarantees around
facts shipped with core Facter and Facter as an API.
As in, you have Facter 2.2.0 with Facter Core Set 1.0.3 or some such. Make it
more like stdlib, where you can iterate more quickly on the facts themselves
than the fr
[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 wrote:
> On 2014-08-28 00:51, Kylo Ginsberg wrote:
>
>> But going forward there's a question about how to handle changes to fact
>> *values*. One proposal is that w
