How to add additional "generator" commands?
Description
I am looking to extend the ChefDK generator so that we can do things like chef generate library helpers which will generate the libraries directory and the libraries/helper.rb file with all of our standard boiler plate and the standard module layout we use for Coobook Libraries.
ChefDK Version
working with 1.6.1, but have confirmed this in a current 2.4 ChefDK
Platform Version
CentOS 6.9, but confirmed on other platforms as well.
Replication Case
Have attempted to add the following to .chef/knife.rb (though not all at once)
if defined?(ChefDK)
puts 'this is a test'
chefdk.send(:generator, :xxxxxxx, :MyLibrary, "generate my lib")
end
...
ChefDK::Command::Generate.send(:generator, :library4, :MyLibrary3, "Generate a libarray!")
...
require_relative './test_gen'
require 'chef-dk/generator'
include ChefDK::Generator::Context
include ChefDK::Command::Generate
include ChefDK::Command::MyGenerate
generator(:xxxxxxxx, :MyLibrary, "generate my lib")
...
before do
ChefDK::Command::Generate.send(:generator, :library, :MyLibrary, "generate my lib")
ChefDK::Generator::Context.add_attr(:zzzzzzzz)
ChefDK::Generator::Generate.class_eval{ generator(:yyyyyy, :MyLib, 'whatever') }
end
...
# Following the Nordstrom Julia Pattern: https://github.com/Nordstrom/chefdk-julia/blob/master/lib/chefdk/julia.rb
# Created: lib/chefdk/addcommands.rb
Module ChefDK
Module AddCommands
require ChefDK::Command::Generate
generator(:xxxxxxx, :MyLibrary, "generate my lib")
ChefDK::Command::Generate.generator(:yyyyyyyyy, :MyLib, "yyyyyyyyyyyyyy")
def self.path
File.expand_path(File.join(File.dirname(__FILE__), *%w(.. ..)))
end
end
end
# then generated a gem, installed it and included the following in knife.rb
if defined?(ChefDK)
require 'chefdk/AddCommands'
chefdk.generator_cookbook ChefDK::AddCommands.path
end
...
# in same gem, created lib/chefdk/command/generate.rb
module ChefDK
module Command
class Generate < Base
generator(:xxxxxxx, :MyLibrary, "generate my lib")
end
end
end
When I run chef generate I would expect to see xxxxxxx or library or yyyyyyyy as options, and if not displayed there, be able to run chef generate xxxxxxx and have it load my library.
If I edit /opt/chefdk/embedded/lib/ruby/gems/2.3.0/gems/chef-dk-1.6.1/lib/chef-dk/command/generate.rb
I am able to add
generator(:xxxxxxx, :MyLibrary, "generate my lib")
And then run chef generate and see my xxxxxxx option. (That then tries to load ChefDK::Command::GeneratorCommands::MyLibrary, which I think is a whole other problem and, I think, easily dealt with if you create a lib/chefdk/command/generator_commands/my_library.rb and require_relative...)
Stacktrace
Not really applicable as no error message is generated.
@cheeseplus Hi there, is there an update on that?
Moved this to the correct repo (chef-cli) and triaging it.
I think there are a couple ways to approach this issue. To describe it another way - it seems like you specifically want a way to create Cookbook libraries (libraries/helper.rb) from some boilerplate. That seems like a reasonable request - we could drop a file in there that has boilerplate code and commented out code to help users create their libraries easier.
Rather than hacking that functionality into Chef Workstation from an external view I would suggest we just include it as a feature. I don't know that we would create a chef generate library command but perhaps there is a generator setting we could expose that would auto-create 1 boilerplate helper library. If there was a boilerplate library included in every chef generate cookbook that started as a no-op but could easily be modified, would that solve your use case?
Another option is to use a customer cookbook generator. Unfortunately we don't have documentation on how to do that, so that is another issue that this issue spawns. Create documentation about chef generate generator and how to use the created generator. That allows users to customize their cookbooks without adding features into the core codebase that cause sprawl or create an undue maintenance burden.
Also thank you @qubitrenegade for the report and pointing out these issues for us!