I rely on spec tests

but if someone wants to write a puppet-lint plugin to detect old functions...

I have yet to start on stdlib 9, but I'd rely on spec tests as well

that would help!

and yes, lint could probably do that easily

ok thanks. Need to see if i can invest the time in writing one. First need to check how write a plugin for it.

bastelfreak: I'm looking at lint plugins and see you did work to release https://github.com/voxpupuli/puppet-lint-variable_contains_upcase but I think we should archive that since the "future" parser is the current parser and failure to comply is a compile error instead

but https://github.com/voxpupuli/puppet-lint-variable_contains_upcase/blob/master/lib/puppet-lint/plugins/variable_contains_upcase.rb is a very good example of a simple plugin

you can also use function_indexes to get all functions, so the check will be something like function_indexes.each { |function| token = function[:tokens].first ; if deprecated.include?(token.value) notify() end }

and store a hash of deprecated functions and their replacements

then in fix(problem) you use the same hash to replace it

ewoud: thanks for the hints. Will take me some to understand everything, testing and write the spec tests.

I got a minimal version of it I think, checking the last bits

nice! i am still not so confident in the ruby world 😅

Hello Community, I am currently extending the the puppetlabs-postgresql module to add the option to create postgresql instances. I am currenty getting the following error from the

postgresql_conf

type and provider:

Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement,
Cannot alias Postgresql_conf[port_for_instance_test1] to ["port"] at
(file: /root/puppet/modules/postgresql/manifests/server/config_entry.pp, line: 85);
resource ["Postgresql_conf", "port"] already declared
(file: /root/puppet/modules/postgresql/manifests/server/config_entry.pp, line: 85)
(file: /root/puppet/modules/postgresql/manifests/server/config_entry.pp, line: 85, column: 3)
(file: /root/puppet/modules/postgresql/manifests/server/instance/config.pp, line: 196) on node foo

I had a look at the underlaying

Puppet::Provider::ParsedFile

provider and it seems very complex. I would like to add a 'key' property to the postgresql_conf type:

newproperty(:key) do
    desc 'The Postgresql parameter to manage.'
    newvalues(%r{^[\w.]+$})
  end

So far the easier part. Is it possible to add the key property also to the provider or does the underlaying

ParsedFile

limit this? And what needs to happen make the resource unique? I have limited experience with type and provider development and would ask for help here Posted in #puppet

See the

puppetlabs-postgresql

module at https://forge.puppet.com/puppetlabs/postgresql?src=slack&channel=voxpupuli

bleh, looks like the function_indexes is not as useful as I thought since it doens't contain the function token itself

ewoud: but with some work of matching and gsub it should be possible, or? so for example matching has_key() can be

/\.has_key\(/

or

/\shas_key\(/

and can be replaced with

$key in $array_or_hash

something like that yes

it can throw some false positives on large codebase I believe..

though.. anything can throw false positive on a large codebase..

I doubt it, since it doesn't use regexes but rather a lexer, so you already know you're inspecting a function token

https://github.com/ekohl/puppet-lint-stdlib_deprecated in case anyone is interested in picking it up

I think https://github.com/ekohl/puppet-lint-stdlib_deprecated/blob/master/lib/puppet-lint/plugins/stdlib_deprecated.rb provides a decent structure to expand on

right now it doesn't detect x.is_array but does detect x.is_array() because puppet-lint doesn't recognize it

bastelfreak: I am working on https://github.com/voxpupuli/puppet-nginx/pull/1560 and will push to your branch… unless you request me NOT to do so ;-)

smortex: awesome, feel free!

I guess we can add the "right" data types with Variants in this PR and issue deprecation warning(errors) when the wrong type is used; and open a sibling PR that remove the "wrong" data types for a future major release?

yes

javing datatypes at all is a big win because it allows us to enable the puppet-lint plugin to enforce types for new parameter