I'm not sure if I agree completely here.
File_line is something that could be used to accidentally screw up a system
but so it pretty much everything else if you don't use it properly. File
templates, custom types, etc... Code review and deployment test gating is
the only way that I can think of mitigating accidents and this is extremely
useful for the one-off "stick a line in here if it doesn't exist" scenario.
I can see the *YAML/JSON files being useful for collecting configuration
data on the back end for those that need to import data from elsewhere.
That said, I agree that Hiera should be used for this.
The concat function does what I generally expect from stdlib. It exposes
base Ruby functionality for use directly within Puppet. I feel that
removing this type of function would warrant exposing some of the base ruby
functions natively for use on primitive types.
I don't find this confusing because I call the concat type as concat {
'foo': } and the concat function as $foo = concat($bar, [1,2,3,4]) and it
would certainly not parse if I tried to shove a hash in there.
Ultimately, I don't feel like we should dictate what might be dangerous to
anyone unless it is inherently dangerous (misrepresentative name, shown to
be prone to misuse, buggy, etc...). A tool is a tool and it's all in how
you use it and what you need in your installation.
Thanks,
Trevor
On Tue, Feb 11, 2014 at 2:29 PM, Daniele Sluijters <
[email protected]> wrote:
> I was browsing through stdlib and I noticed that there's quite a few
> things in there that make me itch, from a little to a lot very much. Most
> of them are workarounds for features missing in the Puppet language and
> though I understand why they exist a few are a bit iffy.
>
> To take an example, file_line is one of those things I consider dangerous.
> Though useful in the absence of better augeas integration or changes to
> ParsedFile it's something that can be very easily used to accidentally
> screw up a system.
>
> I'm also extremely weary of loadyaml, parsejson and parseyaml. Loadyaml
> imho shouldn't have to exist, just use Hiera for that. I'm also not
> entirely sure what the use case for parseyaml would be as YAML is hardly a
> nice format to pass in as a parameter to a class. Parsejson I can
> understand in the absence of structured facts and until stringify_facts
> starts defaulting to false.
>
> Then there's the fact that stdlib has a concat function and that there are
> at least 3 concat modules out there that do something completely different
> which can be confusing.
>
> All in all, what I'm getting at is that perhaps a few of these things
> should be moved out of stdlib into something like stdlib-dangerzone and
> hopefully in time just entirely go away.
>
> On Friday, 24 January 2014 14:12:05 UTC+1, henrik lindberg wrote:
>>
>> On 2014-24-01 11:29, Erik Dalén wrote:
>>
>> >
>> > Well, there is one big problem that we would like to solve, and
>> that
>> > is how functions are called. The ambition is to deal with this in
>> > Puppet 4 timeframe. The problem with the current calling convention
>> > is (among other things) that undef gets translated to an empty
>> > string - we would like to stop transforming values that way. The
>> > idea is that a function can opt in to the 4x calling convention.
>> >
>> > There may not be any functions in stdlib that will benefit from the
>> > calling convention change though (have not reviewed for that yet).
>> >
>> >
>> > count, min & max would definitely benefit from that. They all make some
>> > ugly workarounds for it now.
>> >
>> > In the case of min & max it is mostly the conversion of numbers to
>> > strings (which only happens sometimes in puppet 3.x) they have to
>> > workaround. Will this also change in the 4.x function API, so numbers
>> > are numbers?
>> >
>>
>> Currently (i) In 4x numbers are numbers, but strings are also
>> automatically coerced to a number when a number is required. The reverse
>> is not done. The result of a numeric operation (+,- etc) is always
>> numeric.
>>
>> (i) I say currently (3.5. future evaluator), because no final decision
>> has been made regarding automatic coercion string -> numeric. i.e.
>> should we drop this and require explicit string to numeric coercion?
>>
>> It is questionable how far automatic coercion should go; if declared
>> type is Array[Integer], and there are strings in the given Array, should
>> a new array be produced, etc.
>>
>> The intention is to make the 4x Function API include typed signature
>> support, and thus if a String is given where a Numeric is required will
>> automatically coerce the given String to numeric. We have some design
>> left to do on this, for simple functions it is trivial, but for
>> functions with several overloaded signatures it may get a bit messy.
>>
>> - henrik
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/33bc8a4e-e1e4-46f2-b6c1-b9edabf757e2%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[email protected]
-- This account not approved for unencrypted proprietary information --
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoX1WFjYmrhVJ-iXQONcbzatzhQ0vbdBZ%2BMeNE%2Bz2bEucg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
