Re: pdk 0.3.0

David Schmitt

Hi folks,

apologies for the late reply, first I was out on PTO, then the 0.5 release happened :-)

On 2 July 2017 at 09:22, Thomas Mueller <thomas@...> wrote:

Am 30.06.2017 um 21:36 schrieb David Hollinger:

[Edited Message Follows]

Awesome! Thanks for the work!

A few notes:

On puppet 5.0.0, I'm seeing a rubocop error:
pdk (FATAL): Failed to render template '.rubocop.yml.erb'
RuntimeError: no defaults for rubocop 0.47.1 available
The pdk template only works with and for rubocop 0.47.1 (see Notably, the pdk gemspec doesn't say so, but I'll get that fixed.
Was also perusing the pdk-module-template repository and noticed 2 files that seem a very work environment-specific:

appveyor.yml.erb - generates an appveyor.yml file. Not all customers use this. In fact, just at work and within VP alone we have .gitlab-ci.yml and .travis.yml. I'm sure other orgs and customers use their own choice of tooling, like Jenkinsfile with Jenkins.
The default (open source) template supports an open source workflow. Figuring out the appveyor file (or, even it's existance) is much harder than removing it after `pdk new module`. This is why we want to promote a more featureful default template. Over time I expect the PDK to grow some feature flags, or similar, so that you'll be able to choose the CI integrations when creating the module.


.project.erb - generates a geppetto .project file. I'll be honest - I didn't think this was a maintained IDE anymore, but that notwithstanding, this again comes down to work environment. We use RubyMine here (with VSCode and NeoVIm as backup editors). This is definitely a file we wouldn't need and may not want.

That must have slipped through. You are quite correct. Geppetto is not maintained anymore. Sadly.

Is there a purpose behind having these in the PDK template or should there be a discussion to either remove all CI and IDE config files altogether or create logic/templates for the most commonly used tools?

I agree with David that the default template might be opinionated by including things like .appveyor.yml, .project, .travis.yml . For custom module development in environments without internet access they might not be desirable.

There is also always the possibility for organisations to customize the template for their local requirements. Obviously I would prefer everyone using the main template, and contributing back to the commons, but that doesn't help folks with unique requirements.

Cheers, David

Join to automatically receive all group messages.