Hammer CLI

FYI.. my expectation is that the following command will execute

bundle exec bin/hammer -u admin -p changeme subscription upload --organization-label DemoOrg --file /tmp/manifest.zip --repository-url 'https://cdn.redhat.com'

tomas, do you think this should all be rolled up into the build_options command?

maybe something like

build_options(:expansion => {:only => [:organizations]})

# or

build_options.expand.only(:organizations)

and

build_options(:expansion => {:except => [:activation_keys]})

# or

build_options.expand.all.except(:activation_keys)

i prefer the second way because it reads more like english, but i have a feeling that way would be more difficult to implement.

this would still work with the current options that we may want to pass to build_options like :without, etc.

build_options(:without => [:system_id]).expand.all.except(:activation_keys)

My first idea was to simply extend the command with

searchables_for :activation_keys

Your idea look more elegant. I also like the fact it is separated from the command. I'd go for:

build_options.without(:system_id).expand(:all)
build_options(:without => [:system_id], :expand => { :except => :activation_keys })
# or
build_options.without(:system_id).expand(:except => :activation_keys)
build_options(:without => [:system_id], :expand => { :except => :activation_keys })

The way out of it could be something like:

build_options do
  without(:system_id)
  expand(:activation_keys, :operatingsystems)
end

that could work.

build_options do |o|
  o.without(:system_id)
  o.expand(:activation_keys, :operatingsystems)
end

I like that. and it also solves our problem of calling methods on an already returned method. This way, it all happens inside of build_options.

Cool. The argument "o" can be a very simple object that builds the config hash. I like that -> agreed:)

i like it! +1