Question about tooling support (PDK and VSCode extension)

[melck]

Hi,

I noticed that the puppetlabs/puppet-vscode extension still appears maintained, but the Puppet Development Kit (PDK) seems to have been internalized by Perforce and is no longer actively maintained.

What’s your stance on the future of PDK? Do you plan to fork or maintain a version working with openvox-agent ?

Thanks for your work!

[rtib]

I liked PDK and was involved in developing its templates. It's not disappointing enough that it's no longer available as open source, but it's also missing as a tool. However, I'm not particularly enthusiastic about reviving it. Instead, I have ideas for a modern, similar tool and extending the Puppet module infrastructure.

The VSCode extension however, would make sense even without the PDK integration. IMO, auxiliary tool integration and language support for Puppet DSL should be provided by separate extensions to VSCode.

[Ph0B1uS]

I use PDK a lot and think it's still a decent tool, that being said I'd be happy to see a different take on it.

The commands me and my team use the most are probably
pdk new class & pdk validate though we have to fool the second one as flat out refuses to run unless there's a "puppet" in the requirements section of the metadata.

[hseagle2015]

FWIW, I too rely on PDK a lot. I'm mostly using features such as pdk new (module|class), pdk validate, and pdk test unit. Parallel validation with autocorrect is a life saver.

[rtib]

So it seems we agree that some features might be worth keeping, but does it need to be a single tool? I mean, some features e.g. validate and test unit are just wrapping rake tasks of other gems, like puppet-lint, rubocop, etc. Autocorrect is an optional feature of lint and rubocop. The release and upload tasks are also provided by blacksmith.

Templating a new module boilerplate is redundant between puppet module generate and pdk new module. The other pdk new subtasks for templating classes, defined types, functions, etc., could be implemented, but it needs to be cleared where to put in and I'd suggest to not overdo it as pdk did, by adding lots of things unneeded in many environments like, CI pipeline definitions, devcontainer, etc. which grow messy fast.

I'd propose to separate the concerns and build different tools for development, i.e. creating and extending modules, for testing and for the packaging, release and publish workflows.