Provide a Vox Pupuli alternative to PDK

[rwaffen]

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

[jstraw]

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]

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]

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]

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]

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.

1. New module creation
2. Module Maintenance and features
3. Retrofit old modules

Of course we need an easy way to

• test
• validate
• release
• deploy
• notify

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]

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.

TThe 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.

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]

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

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]

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]

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]

If there's a local gem mirror, is that still count as an airgap?

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]

@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]

The new tool should be self containing, so it is easy to use in airgapped environments.

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]

something like pre-commit, where you can add repos with custom/3rd party/local hooks?

[silug]

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 run pdk build from Ruby code.