Repository navigation
Provide a Vox Pupuli alternative to PDK #68
Description
We should provide for new and existing users of OpenVox an easy and approachable way to get started with a new module.
In the past there was the PDK, which may not be the best, but it was something.
Now we as Vox Pupuli should provide a better approach, which is also more manageable from the tech side.
Key point should be:
- low effort for users
- fancy tools, but also keep in mind strict environments
- for example containers might be bad for high security, older or gov orgs
- integrates well with our other tools
- integrates maybe well with ci
- this can maybe be outsourced to another tool like voxbox
- dependencies should be easy manageable
- maybe there is a way to bundle the dependencies and ship it as one package
- reduce our own boilerplate even more
@binford2k mentioned cookycutter
PS.: feel free to updated, move, change this issue if it's not fitting anymore
Reacted by Kenyon Ralph, Yury Bushmelev, Björn Thoor, Alexander "Ananace" Olofsson, Sasa Tekovic, techsk8 and Joaquin Menchaca
Activity
jstraw commentedon May 20, 2025
most of this can be accomplished by wrapping bundle and modulesync.
I'd say reuse pmt, but I don't particularly want to deal with go templates, I'd prefer we stick to erb or jinja2 and something easily compatible with system python or system ruby.
binford2k commentedon May 20, 2025
My big requirement is that it not be a massive monolith again. I don't care if we create a single entrypoint, but the various tools themselves need to be small and self-contained. The module code generator should not be the same thing as the spec runner. The developer UX should not be the same thing as what runs in CI. Adding a tool or feature to the devkit should not require understanding a complex indirector.
jay7x commentedon May 21, 2025
It'd be nice to have a tool, that bundles the Ruby and all the gems in it, so end user should not care about Ruby management (think about enterprise and compliance). Using containers is easy, but hard to negotiate with security teams in some environments. Not sure if it's possible to make PDK better with those restrictions in place..
Ph0B1uS commentedon May 22, 2025
PDK made the barrier of entry into module development significantly lower for me personally and I love the fact that it contains an easy way to set up new modules, classes and validate the code afterwards too.
That being said I do think that the idea of NOT designing another monolith to take its place is a very good one, can't say that I have any ideas on how to maintain the ease of use when going for a more modularised approach though.
logicminds commentedon Jun 11, 2025
Many years ago before PDK was created I wrote puppet-retrospec which was famous for auto generating unit tests. It worked well for me but acted more like cookie cutter than PDK. This tool was a two part system that used a parent tool simply called retrospec with a plugin system.
The idea was simple. Make the puppet module sexy with all the best practices by retrofitting it. Or start from scratch. At one point puppet-retrospec had more ways to create module components than PDK. But PDK was also about switching rubies and puppet versions which I found value in that. I eventually stopped development on retrospec because puppet 5 removed some features I used but it was the closest thing to PDK since it only focused on content generation.
Modulesync solved a different problem in that it kept modules up2date and was also based on a template system. Did not work well with PDK templates.
I was a big supporter of PDK. Even though it was similar to my tool, the ecosystem really needed a supported tool and I pushed it to all my clients because it really did ease the pain.
A future tool should take all three methods into consideration as there are several phases of module development.
Of course we need an easy way to
My thoughts are that since module sync is so pervasive and good already, a wrapper tool would be needed (as stated above). The retrospec framework I built could be that wrapper tool and it could be compiled into a "single binary" like pdk with some other ruby tooling as well to make it easy to get started. But are we not just re-inventing the same thing?
My next question is:
Would building an agentic service to create a scaffold that is described by the user via AI prompt be the next thing? Why scaffold when we can describe. But this is a whole new topic.
Just an example: https://chatgpt.com/share/6848d9d8-f168-8004-851d-24119120827c
jstraw commentedon Jun 11, 2025
Please keep AI crap away from me. I don't want or need an LLM anywhere near a toolset that modifies things as root (even a few steps removed)
I would prefer to do something like git where the subcommands are all their own binary (git-*) over a single binary.
I agree that the access point shouldn't be the same, but what it does should be as close to identical as possible. (Running tests in this tool should do the thing in the way that CI does it, so if you succeed one, you are sure that it will work in the other.
jay7x commentedon Jun 11, 2025
That reminds me about cirrus-cli - a tool that allows you to run a Citrus CI/CD pipeline locally (in a container or a VM, as described in the pipeline config file). That's amazing experience, when you can just run the same pipeline steps locally. It's like a Makefile, but with every target isolated. But... it requires docker (didn't try with podman) :(
tuxmea commentedon Jun 11, 2025
The new tool should be self containing, so it is easy to use in airgapped environments.
Many of our customers don't allow internet access. The only way to get tests working at the moment: place the pdk package on a local mirror.
The new package should have everything it needs to be able to run without internet access.
jstraw commentedon Jun 14, 2025
I am fine with targetting airgap, but I think that's a secondary goal. Lets get a working system (knowing we want to support airgap) then add the airgap capability.
If there's a local gem mirror, is that still count as an airgap?
tuxmea commentedon Jun 16, 2025
Any local repo is considered to be air gapped.
It is more a question how to transfer the gems into the environment.
The most simple (and already used) way is containers (e.g. voxbox already is on a local registry at several airgapped customers).
binford2k commentedon Jun 17, 2025
@jstraw what I meant about developer UX vs. CI wasn't the tests that were run, it's the interface. For example, some early versions of the PDK were famous for crapping out thousands of lines of
because they neglected to plan for CI usage and it tried to render a spinner into the logs. And at the same time, we don't want local developer usage to spit out GitHub CI check annotations to your console while running
rake spec.binford2k commentedon Jun 17, 2025
Rather than making the tool itself fully self-contained, can we build another tool(s) to fit into the suite that would let users manage their own offline cache(s)? Whether that's eg containers or RVM gemsets or artifactory mirrors is open for interpretation.
rwaffen commentedon Jun 18, 2025
something like pre-commit, where you can add repos with custom/3rd party/local hooks?
silug commentedon Jul 15, 2025
For reference, I was just reminded of a feature of pdk that I use:
pdk build. I'm sure there are myriad other ways to build a module, but I do like the simplicity of being able to specify files to ignore in.pdkignore(which works like.gitignore), and the pdk gem makes it easy to runpdk buildfrom Ruby code.jokreliable commentedon Aug 18, 2025
I am interested in helping with docs/guides/tutorials/references.
my personal usage is just as a helping tool for creating modules/classes/etc and to run unit tests locally (and in CI). It would be nice to have something that also handles other kings of tests (maybe relying on beaker for that specifically).
krisavi commentedon Jan 5, 2026
PDK also had integration to the vscode as extension. It provides simple auto-completion there.
Basically some alternative to https://puppet-vscode.github.io/ that doesn't need pdk would be good for users. If in the background pulls multiple smaller modules or one monolithic thing doesn't even matter that much.
Generally it is more required to simplify entry into developing puppet modules. In current form it seems to be something that only people familiar with puppet can easily do. For new people it seems quite complicated to get into development.
jay7x commentedon Jan 5, 2026
@krisavi You don't need PDK for this. The extension can use puppet agent instead. Click in the status bar, in very right corner, just before the "bell" icon. I guess you should have PDK there. Though, you should be able to select Puppet in the drop-down menu after as long as you have Puppet/OpenVox agent installed.
nsballmann commentedon Jan 13, 2026
This seems to become more important as Perforce decided to not publicly release PDK anymore.
Last Open Source release of PDK was 3.4.0:
But there were PDK releases since:
But to quote https://help.puppet.com/pdk/current/topics/pdk_install.htm:
avitacco commentedon Mar 5, 2026
I'm not sure if it is of interest to the community at large, but I've started working on a tool I call "hammer" (horrible name, I'll admit). It is written in Go and is meant to replace pdk for some functionality, specifically
pdk new [...],pdk build, andpdk release.The plan is to embed default templates in the binary with an option to use externally defined templates as well.
Being written in Go, replicating
pdk validate,pdk test unit, andlitmusfunctionality will be challenging. If I can find an easy way to accomplish it, I might try to add that later.corporate-gadfly commentedon Mar 5, 2026
hammeris also the CLI on foreman, so it will be very hard to disambiguate (given the proxmity of the two projects).avitacco commentedon Mar 5, 2026
Ahhh crap, I was hoping to find something that wasn't like
go-pkd. I suspected hammer was taken by something else in the ecosystem, I'll have to rethink it. I'm open to suggestions :-).Edit: would something like voxdk be too on the nose?
jay7x commentedon Mar 6, 2026
You may want to check
pctmade (and deprecated) by perforce while ago. I did a refresh of it here: https://github.com/jay7x/pct.logicminds commentedon Mar 6, 2026
Looks similar to what I created https://github.com/nwops/retrospec. These are all static file generators based on templates. Which only solves some of the problem. If I had to do this again I would just pick a compiled language and shell out to ruby when needed. However, issue is trying to solve an opinionated workflow problem which provides shortcuts for users. Creating the path of least resistance for anyone writing a module or interact with the ecosystem.
krisavi commentedon Mar 6, 2026
Unfortunately you do need it... For me it worked on my old laptop since I had PDK downloaded and installed when it was still available and the plugin still functions. PDK provided linting function. Agent itself doesn't provide much for the extension. On new laptop I haven't been able to get it working.
NeoVim and Mason are struggling to install puppet language highlighting as well. Update at least didn't work and had to manually symlink some of the binaries towards PDK that was installed via homebrew.
nsballmann commentedon Mar 6, 2026
For a new name, what speaks against
ovdk? OpenVox Development Kit? Maybe, reserving the name for an actual fork ofpdk(if possible due to licensing)?avitacco commentedon Mar 6, 2026
Exactly that, as this is my personal project, it feels like flag planting to name it ovdk. I don't want to hijack this thread further with the discussion of my project's name; there's an issue for it in my repo all are welcome to participate there.
nsballmann commentedon Mar 6, 2026
No worries, I consider my comment more of a general question/remark for the original issue.
cvquesty commentedon Mar 13, 2026
Man, I so appreciate everyone on this thread. Put my hat into the ring of "a single easy set of commands, standalone operation, and out-of-the-box testing with a low barrier of entry to users".
WHATEVER the toolset... for me it's more providing a way of working than a specific tool.
avitacco commentedon Apr 14, 2026
Now that I have gotten jig to v1.0.0, I'd like to explore making template changes and adding functionality to better solve the problems this community needs solving.
Currently, the application has the same functionality as
pdkexcept withoutvalidateortest unit. I'd like to make changes to the default templates to better match the OpenVox testing framework's needs and explore adding a command that could pass testing off to existing commands.Thanks in advance!
nsballmann commentedon Sep 18, 2026
Another thing that I want you to make aware of is copier (not knowing if it's already in use).
On first glance it just looks like a generic project templating tool. The thing that copier IMHO does better than all of the other templating tools is that the template is versioned and that feedback loops into existing projects exist.
This means as an maintainer, if you set up RenovateBot or similar, you will get automatic MRs/PRs for template updates that result from learnings in the projects/modules that use the template. That way as a maintainer you are still in control if you want to take the template changes in or not. You will easily see conflicts in case you deviated from the template.
copier additionally can ask specific questions when initially creating a project/module and maintains those answers for the future template updates. The usual example is CI, e.g. should GitHub or GitLab CI files be generated. I'd usually argue both as this simplifies moving from one platform to another if the CI portion of the template is maintained equally. In the Puppet/OpenVox context I would expect a question like "Is this a control repo or a module repo?".
I would help with maintaining a copier puppet/openvox template. And this template could then refer to
jig,pdkor any other tool for specific aspects around module and control repo development.WDYT?