Add missing paths to allowed module layout #158
Conversation
language/module.md
Outdated
| @@ -45,6 +45,12 @@ already explains what a module is and what it can contain. | |||
| | `/lib/puppet/type/` | Custom types | | |||
| | `/lib/puppet/provider/` | Custom provider for one or multiple types | | |||
| | `/lib/puppet/functions/` | Modern functions in Ruby for the new API | | |||
| | `/lib/puppet/datatypes/` | Custom Puppet Datatypes | | |||
There was a problem hiding this comment.
is that the same as /lib/puppet/type/?
There was a problem hiding this comment.
No, /lib/puppet/type/ is for Resource Types. /lib/puppet/datatypes/ is for custom data types. "Type" is overused in Puppet, but ah well. You can see an example here: https://github.com/hlindberg/tahu/tree/master/lib/puppet/datatypes/tahu
There was a problem hiding this comment.
I pushed an update which clarifies "Resource types" in the type and provider lines.
|
I'm not sure which schema/changelog Puppet likes to have. the bottom of the page mentions it. should we add a new section with a changelog and increase the schema version? |
Also, clarify Resource Types vs. Data types in the various path descriptions.
seanmil
force-pushed
the
add_module_paths
branch
from
8a5611d to
743e91d
Compare
| | `/lib/puppet/datatypes/` | Custom Puppet Data types | | ||
| | `/lib/puppet/face/` | Custom Puppet Faces | | ||
| | `/lib/puppet/feature/` | Custom Puppet Features for providers | | ||
| | `/lib/puppet/property/` | Custom Puppet Properties for Types/Providers | |
There was a problem hiding this comment.
There's also /lib/puppet/parameters
There was a problem hiding this comment.
Also /lib/puppet/applications and /lib/puppet/reports
| | `/lib/puppet/type/` | Custom types | | ||
| | `/lib/puppet/provider/` | Custom provider for one or multiple types | | ||
| | `/lib/puppet/type/` | Custom Resource types | | ||
| | `/lib/puppet/provider/` | Custom provider for one or multiple Resource types | |
There was a problem hiding this comment.
Technically, modules can put whatever they want in the /lib directory and it will be packaged in the module and pluginsynced to agents. So from an allowlist perspective, listing individual /lib/puppet/* directories is misleading. But from a "what are the various extension points" perspective, it's informative.
There was a problem hiding this comment.
Technically, modules can put whatever they want in the /lib directory
is that something that we should allow here? Do you have anything in mind that isn't already covered by the different /lib/puppet/ subdirs?
There was a problem hiding this comment.
is that something that we should allow here?
I think we should allow anything under /lib since that's how puppet behaves today. For example, there was some early confusion about /lib/puppetx vs /lib/puppet_x. And given /lib/augeas there may be some others?
In the future, I think it would be good to document which extension points are allowed in the /lib directory and add a deprecation warning to if we detect a dir/file that isn't allowed during pluginsync. Then in a major release, only pluginsync files that are in the allow list.
There was a problem hiding this comment.
add a deprecation warning to if we detect a dir/file that isn't allowed during pluginsync
Do you think it's realistic to introduce the warnings in Puppet 8 or maybe with Puppet 9.0?
No description provided.