| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 409a974095a3f5b637e091494b5d14b451c5de78.
After thinking about this, use case, and function naming, I think it's
probably best for now to keep things simple and let `fact()` be
single-purpose for looking up facts with no potentially confusing
extensions. The only use case where the name makes sense is where it's
being used on the `$facts` hash, and I think we'd rather in that
circumstance promote the raw use of `fact()`.
|
|
Because sometimes people want to use an alternative data set, but treat
it like it's a set of facts.
|
|
The fact() function allows dot-notation reference to facts. It is an
alternative to using $facts directly with array-indexing. Array-indexing
is often onerous to use since it doesn't align with how structured facts
are accessed elsewhere in the ecosystem and if any element in a
multi-step path doesn't exist, array indexing can cause a compilation
failure.
Example usage:
fact('os.family')
|
|
|
|
Prior to this commit, users coming to the type_of function would not realize that the type function in puppet does the same thing and is preferred over type_of.
After this commit, we have a comment indicating the above.
|
|
A previous PR (#685) was raised on this issue, however once it was merged it was discovered that Puppet 3 with future parser enabled was calling the Puppet 4 version of the deprecation function. The Puppet stacktrace is not available until Puppet 4.6, so this was breaking existing setups. The solution was to check is the stacktrace was defined, and if it was to use it as part of the message output.
|
|
|
|
|
|
This is a workaround for PUP-4438 (fixed in https://github.com/puppetlabs/puppet/commit/e01c4dc924cd963ff6630008a5200fc6a2023b08, 4.1.0, 3.8.1).
It works by manually passing through the scope, instead of relying on the
InternalFunction class.
|
|
This now emits one deprecation warning for each function used (but not for each call-site). Prior to this, only a single deprecation warning would have been triggered, potentially misleading users.
Additionally this adds v4 deprecation stubs for the functions that were missed.
|
|
|
|
This reverts commit b63862ff43194194f7428739a32cfe13bad1e7ed, as it would
only show the irrelevant first entry of the ruby stack trace. The
puppetserver log does contain the full trace information, or you can use
--strict=error to cause a hard failure when hitting a deprecation.
# Conflicts:
# lib/puppet/functions/validate_legacy.rb
|
|
|
|
This was not working when the puppet master did not have the newest stdlib
version in its environment.
|
|
|
|
|
|
|
|
* validate_legacy now accepts undef values
* update the TypeMismatch message to include the original validate function name
* only notice, not warn, on newly allowed values
* changed previous_validation to function_name to avoid confusion with the function of the same name
* use deprecation() instead of warn(), when hitting a deprecated value
* prepare the tests and function for MODULES-3735
* rewrite validate_legacy tests to use new rspec-puppet
* move validate_re deprecation to puppet4 only
* adapt validate_re_spec
|
|
|
|
|
|
|
|
|
|
The data type system is very hard to understand. Many people don't
understand why
type_of([1,2,3]) == Array
will fail, but
type_of([1,2,3]) <= Array
passes. This does a simpler validation that doesn't rely on explicit
data types. Instead, use
$foo = [1,2,3]
if $foo.is_a(Array) {
notify { 'This is an array': }
}
This is based on code by Ben Ford <ben.ford@puppetlabs.com>.
* Added acceptance tests
* Added dispatch
* Improved unit tests
* Added docs to README
|
|
The `type()` function will cease to work on the new parser because 'type'
is a reserved keyword. The `type3x()` function may be used to continue
similar functionality, but will be deprecated in favor of the built-in
typing system.
The `type_of()` function has been included to introspect types in the
new parser.
|
