--debug, --username, --server, --password appears to be broken

[sepulworld]

Looks like global options in aptly_command.rb are not working presently.

debug_output $stdout L66 in aptly_command.rb doesn't appear to respond and even if you set debug_output $stdout directly in class AptlyCommand it isn't used when running http queries in let's say aptly_repo

$ aptly-cli repo_list --debug --no-config
{"Name"=>"testrepo", "Comment"=>"", "DefaultDistribution"=>"", "DefaultComponent"=>"main"}
{"Name"=>"testrepocreate", "Comment"=>"testing repo creation", "DefaultDistribution"=>"precisecreatetest", "DefaultComponent"=>""}
{"Name"=>"testrepotoshow", "Comment"=>"testing repo show", "DefaultDistribution"=>"preciseshowtest", "DefaultComponent"=>""}
{"Name"=>"testrepo20", "Comment"=>"", "DefaultDistribution"=>"", "DefaultComponent"=>"main"}
{"Name"=>"testrepotoquery", "Comment"=>"testing repo query with name", "DefaultDistribution"=>"precisequerytest", "DefaultComponent"=>""}
{"Name"=>"testrepoedit", "Comment"=>"testing repo edit distro name", "DefaultDistribution"=>"preciseeditdistnew", "DefaultComponent"=>""}

The above command should include HTTP debug output from HTTParty.

[msabramo]

Ah yes, I noticed this too while trying to write a test for --debug. I don't know enough about HTTParty to know how to resolve.

[sepulworld]

I'll take a look and see if there is a straightforward solution.

[msabramo]

https://gist.github.com/natritmeyer/6495044

[msabramo]

http://stackoverflow.com/questions/22414803/httparty-how-to-log-request

[sepulworld]

Would be nice if I didn't have to litter the classes with debug_output $stdout checks, and just have it part of class AptlyCommand

[msabramo]

Hmm maybe have AptlyCommand extend HTTParty instead of include it?

http://stackoverflow.com/a/14212020/638434

If you extend a class with a module, that means you're "bringing in" the module's methods as class methods. If you include a class with a module, that means you're "bringing in" the module's methods as instance methods.

Though the docs say to use include so I don't know.

[msabramo]

Hmmmm.

jnunemaker/httparty#26

[sepulworld]

Ok, it might not a problem with the class inheritance.

When I swap out that L66 in aptly_command.rb for

      if self.class.respond_to?(:debug_output)
        puts @config[:debug]
        puts options.debug
        #self.class.debug_output $stdout if @config[:debug]
        self.class.debug_output $stdout
      end

it works. So, it appears to be an issue with the if @config[:debug] check failing. I see that this hash entry is empty at this point, even when I have --debug in the command.

options.debug is true

[sepulworld]

I think I have boiled it down to

if options.respond_to?(:debug) to passing

[msabramo]

Interesting. Is https://github.com/sepulworld/aptly_cli/blob/master/bin/aptly-cli#L54 getting executed?

[sepulworld]

It is... when I do some 'puts' debugging I see it come through.

When I inspect the 'options' object

puts options.inspect
<Commander::Command::Options debug=true, no_config=false>

puts options.respond_to?(:debug)

returns empty line

[msabramo]

I wonder if the commander Options class might have its own debug method that we're clashing with?

[msabramo]

If I were at a keyboard, I think I'd put a require 'pry'; binding.pry where $debug gets set.

[sepulworld]

Maybe, but I also see similar behavior with other options.

if options.respond_to?(:server)

Looks like they are all missed upon respond_to? check. Using Ruby 2.3.0...

[sepulworld]

Ok, Ill checkout with pry, good call.

[sepulworld]

So, I think why the tests passed originally is because we create the options object with Options.new and get an object that looks like this.

responds_to? works for this object...
#<Options:0x007f964662d688 @username="me", @password="secret", @server="my-server", @port=9000, @debug=false>

versus in aptly_command.rb the options object comes from Commander and inspect (seen in pry) shows it as:

responds_to? doesn't work for us here....
<Commander::Command::Options debug=true, no_config=false, server="127.0.0.1">

[msabramo]

Fixed by #137 ?

[sepulworld]

Yes, looks good. I'll close this and work on some functional test using serverspec.