--debug, --username, --server, --password appears to be broken about aptly_cli HOT 18 CLOSED

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.

from aptly_cli.

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

from aptly_cli.

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

from aptly_cli.

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

from aptly_cli.

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

from aptly_cli.

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.

from aptly_cli.

Hmmmm.

jnunemaker/httparty#26

from aptly_cli.

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

from aptly_cli.

I think I have boiled it down to

if options.respond_to?(:debug) to passing

from aptly_cli.

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

from aptly_cli.

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

from aptly_cli.

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

from aptly_cli.

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

from aptly_cli.

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...

from aptly_cli.

Ok, Ill checkout with pry, good call.

from aptly_cli.

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">

from aptly_cli.

Fixed by #137 ?

from aptly_cli.

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

from aptly_cli.