restructuring of main.rb breaks other uses of optparse

[dshorthouse]

Because main.rb has been restructured, it breaks use of optparse elsewhere in my app. I have an environment file in which I require the sinatra gem because I make use of sinatra/config_file. I also have some optparse-based scripts executed on the command line that also require sinatra and sinatra/config_file.

[namusyaka]

Can you provide a minimal example with your Gemfile.lock?

[namusyaka]

Also the regression around optparse was fixed in #1559, have you tried v2.0.7?

[dshorthouse]

Thanks, am on 2.0.7. The following would have worked in 2.0.6 but does not now with 2.0.7:

#!/usr/bin/env ruby
# encoding: utf-8
require "sinatra"
require "optparse"

options = {}
OptionParser.new do |opts|
  opts.banner = "Usage: app.rb [options]"

  opts.on("-p", "--print", "Print some stuff.") do
    options[:print] = true
  end

  opts.on("-h", "--help", "Prints this help") do
    puts opts
    exit
  end
end.parse!

If you execute such a script with sinatra required, main.rb swallows all the params.

[namusyaka]

Well, I have tried the above code in v2.0.5, v2.0.6 and v2.0.7. But I could't find any difference.
Perhaps the code you provided is something wrong for reproducing your issue.

[namusyaka]

Btw, please don't expect v2.0.6 to be correct.

[dshorthouse]

Yes, you are correct. My apologies. However, passing -h or --help with such a script prints the help from sinatra's main.rb and not the params and their descriptions in the script. Do you see the same?

[namusyaka]

@dshorthouse Yes, I can see the same thing, it's expected originally. You can see the same even if using v2.0.5, right? This question is for making sure that your issue is not a regression.

If you wouldn't like to use sinatra as a CLI tool, or would like to overwrite option parameters, you should use sinatra/base instead.

[dshorthouse]

Thanks for this. Indeed, same if using v2.0.5 I see now. My issue is that I'd very much like to register Sinatra::ConfigFile because I have a yaml config to be used via both CLI scripts and a web app. Either of those scenarios require sinatra.

[namusyaka]

At first, I'm completely not sure that your app's definition and its context. So I can say something only about sinatra.

In my understand, perhaps you'd like to use Sinatra::Contrib in both CLI and webapp, right?
This should be sufficient just to use the require 'sinatra/base' that I mentioned earlier.
Calling require 'sinatra' expects the caller executable to behave like a web server. This is the old sinatra practice. Unfortunately, I won't change it.

Probably you should be able to handle sinatra from the CLI as follows:

# foo.yml
foo: bar
something: 42
nested:
  a: 1
  b: 2

require 'sinatra/base'
require 'sinatra/config_file'

class Foo < Sinatra::Base
  register Sinatra::ConfigFile
  config_file "./foo.yml"
  p something # 42
end

[dshorthouse]

OK, thanks for the feedback. Guess I'll just have to restructure what I have as there's no longer a solution. Perhaps there's another gem out there that can do something comparable to sinatra/config_file as that's ultimately what I needed.