Hey Molly, The PDK has already been ignoring the /spec directory for quite some time, so I think this is totally appropriate. It won't even have any effect for PDK enabled modules from the Forge. Those files are only used for development purposes, and if you're doing that in your production codebase, you should go slap yourself on the wrist! 😉
Honestly, I'm not even sure that r10k should offer an option to opt out. If you want the specs to do dev work on the module, then you really ought to just be cloning it into a workspace in the first place. Working directly in a deployed control repo is a real good way to get yourself stuck. If you make changes to files, accidentally or not, you can easily get yourself into the state where r10k or Code Manager can't even deploy cleanly and you'll have to either clean up the repo, or nuke it and redeploy. We've recommended for ages that people just treat the deployed control repo as a black box. Cheers! On Thu, Mar 11, 2021 at 4:07 PM <steverobill...@gmail.com> wrote: > Molly, > > > > Should this be an all or nothing or off by default with the option to > include them? > > > > Thanks, > > Steve > > > > > > > > > > *From:* puppet-users@googlegroups.com <puppet-users@googlegroups.com> *On > Behalf Of *Molly Waggett > *Sent:* Thursday, March 11, 2021 7:04 PM > *To:* puppet-users@googlegroups.com > *Cc:* Froyo Team <team-fr...@puppet.com> > *Subject:* [Puppet Users] [INFO, maybe ACTION] r10k Feature Proposal > > > > Hey folks! > > > > We are planning an r10k feature to stop deploying module spec > directories. This will lower disk usage, particularly for folks with a lot > of modules and multiple compilers. > > > > Our hope is to enable this behavior by default, but leave the option to > opt out (i.e. continue including spec directories when deploying > modules). This is based on the assumption that most folks have no need for > module spec directories in a production environment, since they typically > just include testing materials for module development. > > > > If you think this assumption is inaccurate, or even if it’s just > inaccurate for you, please let us know! If we don’t hear any objections by > *Tuesday, > March 23*, we will proceed with the above plan to adopt this behavior but > include a way to opt out. > > > > If you have any questions, please reply to this email or ping @r10k in the > Puppet > Community Slack <https://slack.puppet.com/>. > > > > Thanks! > > > > -- > > *Molly Waggett* > > she/her > > Senior Software Engineer @ Puppet > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAFOE68C%2BWNLmtfgJgCUkRkjX-rYqoAUAQvUApa-xp1_k7sp7vA%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-users/CAFOE68C%2BWNLmtfgJgCUkRkjX-rYqoAUAQvUApa-xp1_k7sp7vA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/155101d716d3%24aa8c9750%24ffa5c5f0%24%40gmail.com > <https://groups.google.com/d/msgid/puppet-users/155101d716d3%24aa8c9750%24ffa5c5f0%24%40gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACkW_L4cU8qUc5F%2BLPocg0oKogi9ce3C3vw98azGdHGwAqCg2g%40mail.gmail.com.
