1. Matt Chaput
  2. baker
  3. Issues
Issue #9 new

Add global options

Stephen Day
created an issue

It would be nice to have a set of global options, such as verbose that would be available to commands under baker.options. Usage may look like this:



import baker

@baker.command def c(arg): if baker.options.get('verbose'): print "This is verbose"

baker.run(options={'verbose': {'help': 'Turn on verbose output', 'default': False})


I have found it a bit awkward to use Baker when a lot of commands share the same options.

BTW, thank you for the great package.

Comments (11)

  1. Michele Lacchia

    Wouldn't this interfere with a default command? I mean, if you have --verbose as global option, then you would use it like this: script.py --verbose [...]. But that could be a default command's option.

    Maybe we can allow global options and default command but not both at the same time. Probably default commands were introduced for this purpose but I think global options are better for this.

  2. Sylvain Prat

    I guess the default command is very useful when using only one command, to benefit from the baker's simplified syntax for declaring options, compared to OptionParser et al.

    I am not sure how global options could be implemented. Anyway, I'm not really enthusiastic about the proposed example since it violates the zen of python: explicit is better than implicit! It would be better to pass the verbose option as an argument explicitly than to expect it to be found in a dictionary somewhere.

    I would rather write something like this, which is more explicit IMHO:

    def command(param1, **default_options):
      verbose = default_options.get('verbose')
      # process the command

    But I don't know how the keywords arguments are currently handled in baker.

  3. Michele Lacchia

    Uhm, you are right. But what if the command already use **kwargs? We could add an attribute to the function instead, but it's not so explicit:

    def func(arg, opt, *pos, **additional_options):
        if func.global_options.get('verbose'):
            # additional stuff

    and in baker.command:

        fn.global_options = # ...

    But I'm sure there is a better solution.

  4. Sylvain Prat

    Adding the global options to a function attribute is elegant, but it makes the function harder to unit-test: we have to populate this attribute in order to test our function.

    I guess I would simply merge the global options with the command-specific options in case kwargs are used. In fact, I don't see the point of using kwargs in the first place: how are we supposed to document the available options to the user? With :param docstrings?

  5. Michele Lacchia

    Well, it would be populated automatically by the run method, and then we could simply check whether it contains the right stuff.

    As for the kwargs: actually I haven't found a use-case yet. But they were in unit tests and in the original code when I picked it up, so I just left them.

  6. Timothy Corbett-Clark

    Firstly: Baker fits my taste perfectly. There are lots of command line helpers out there but this one is really crisp. It achieves the same quiet power as fabric. Thank you!

    It does lack global options though. So this is a +1 for this ticket.

    I appreciate the "keeping things explicit" point, but global options are meant to be global. I would prefer not to have to mention them in each @baker.command but allow them to be picked up from outside. Two examples are --verbose and --no-colour. The values of these would be picked up by log and error helper functions.

    Of course the docstring should also indicate that they are global and not per command (and also allowed before the command).

  7. Michele Lacchia

    Unfortunaly I have so little time now that I cannot work on this issue myself. If you have some ideas and want to open a pull request I'll review it gladly. Otherwise it will take time...

    I'm really sorry, since I understand the importance of global options and I feel the lack myself when I use baker!

  8. Log in to comment