Puppet Community

manifests/pip.pp:220:manifest_whitespace_opening_bracket_before:ERROR:there should be a single space before an opening bracket

manifests/pip.pp:230:manifest_whitespace_opening_bracket_before:ERROR:there should be a single space before an opening bracket

Yeah, 6.4.0 sounds reasonable, guess I'll redo the version - and probably get another PR up to fix the lint issues

Hmm, though the lint error is odd. There is a single space before the opening bracket, and it really feels like there shouldn't be one

And it's happier without said space, so I guess it's just a message that's not been set correctly

normally when an issue has a PR that fixes it I add skip-changelog to it

Anyone have comments - or a merge-clicking finger - for <https://github.com/voxpupuli/puppet-python/pull/646> ?

Reused the release PR at <https://github.com/voxpupuli/puppet-python/pull/645> - so the branch name isn't as good anymore, but at least CI's green.

bastelfreak I take it back. Will be there

File a `FORGE` ticket asking for it. Have a Vox PMC member approve it

good luck with that. FORGE team told me we need to reach out to the modules team (who dont use jira anymore)

<@U11HA7VJ7> <https://tickets.puppetlabs.com/browse/FORGE-667> I'm not allowed to add watchers.

<https://tickets.puppetlabs.com/browse/FORGE-658> let's see

<@U1PC2RAH0> I think they may have misunderstood. The modules team doesn't need to re-evaluate a module when it changes maintainers

still it raises the question how we should submit issues to the modules team

I would phrase these requests more like vox is assuming maintainership of an approved module, please transfer the approved badge along with it

I will note that the jira workflow for the FORGE project doesn't make it obvious as to how the ticket should be assigned

a template along the lines of "community forge request" would help, if jira is to the vehicle for making requests.

yeah, the user visible workflow isn't super helpful. I agree that would make it better.

<@U1PC2RAH0> related -- I'm sort of assuming that PMC should be the approver for deprecation/badge requests when Vox assumes maintainership of a module. Do you see it like that too?

from a security point of view the forge people should ask the original author if it's okay that their module is being deprecated. but given that most of those people aren't active anymore, that's tricky :smile:

maybe
• [Approved] badge is gated on PMC approval
• Deprecations require approval from the original author; via email request to the account on record

and then maybe we put on the Forge roadmap a "recommended alternative" that would add a pointer to the Vox version of the module, but not actually deprecate the original

I'm afraid that this will heavily slow down the process

do you -want- PMC approval for the badge migration?

when somethins is migrated to us? I don't think so

from the Forge standpoint, they want to know that 1) it's the same codebase that was already approved, and 2) the maintainer will keep QA up to par

I usually provide a link to the old module. when you then click on source you get to the old github url and that redirects to vox pupuli. so you know it is the same codebase because it's the same repo

That works if the original author transfers the repo

ah yes. otherwise you see that we forked it

(Which should imply the depreciation too)

I think a new release of the `console` gem has broken `rspec-github`. I haven't seen this on a voxpupuli repo yet but I'm seeing it this morning on my $day_job repos
```rake aborted!
SyntaxError: /opt/hostedtoolcache/Ruby/2.7.2/x64/lib/ruby/gems/2.7.0/gems/console-1.16.2/lib/console/progress.rb:77: syntax error, unexpected ')'
			@output.info(@subject, ...)
			                          ^```

There's a voxpupli module that just contains ensure_resource type calls for packages, files, services, ... in a generic way to be loaded from hiera. I cannot remember the name or find it.  

See the `puppet-system` module at <https://forge.puppet.com/puppet/system?src=slack&amp;channel=voxpupuli>

We have files and packages in the `site.pp` but nothing else.

bingo. Indeed I don't like the concept much as no longer writing puppet really. .. However given some co-workers determined to work that way makes some sense they don't reimplment the same thing. Will take a look....

sneak a puppet-lint plugin into the codebase that blames ensure_resources()

Still need it for duplicates - certainly ensure_package.

I think that's an antipattern and should be avoided

and usually it's possible by writing proper modules and testing them, but that requires more time/knowledge

there is a new class in puppetlabs-stdlib: stdlib::manage which allows you to add any resource type as hiera data.

See the `puppetlabs-stdlib` module at <https://forge.puppet.com/puppetlabs/stdlib?src=slack&amp;channel=voxpupuli>