Support for unary args

[cjauvin]

This adds support for Xvfb arguments which do not have values (e.g. -noreset).

[cgoldberg]

thanks!

could you create a new test for unary_args, rather than how you added it to the existing test_start_with_arbitrary_kwargs test? If you make that change, I'll be happy to merge this.

-Corey

[cjauvin]

Done, thanks a lot! Also, I have another small change I've been using in my particular context, where I want to control the display variable explicitly (instead of auto-assigning it): if you think it would make sense to add it, let me know.

[cgoldberg]

thanks much.

hmm.. so to add a unary arg, you have to pass it as a kwarg with a None value? (like my_arg=None). That's not very obvious (it took me a few mins to figure it out). At the least, we should update the README with some nice examples showing use of binary and unary args, so it's clear. You can add that to this PR if you'd like. (If that's not convenient, I can just merge as-is and write the examples myself sometime this week).

One other thought.... couldn't we use *args for passing arbitrary unary args?

would something like this work as a signature:

def __init__(self, width=800, height=680, colordepth=24, *args, **kwargs)

then you could for example, initialize the Xvfb object like:

Xvfb(width=1024, height=768, 'noreset', nolisten='tcp')

[cjauvin]

Rethinking about it, I now totally agree that using an argument with a None value (an empty string would make a little bit more sense, and it also works btw) is not the most intuitive interface.

I find your idea of using *args very clever, although there's a part of me thinking that it wouldn't be 100% pythonic as well.. But then the only other alternative remaining would be an explicit server_args argument, with which we would have essentially the same design problems (i.e. it would need to support both unary and binary arguments in the same data structure).

So I vote for your *args idea, I will propose a PR with it soon!

[alkuzad]

@cgoldberg actually I also had problem with argument that does not use "-",
have you thought of supporting passing full args list instead of kwargs ? Xvfb supports at least 4 parameter types:

• starting with -
• starting with +
• without any prefix and parameter
• without any prefix and not parameter

For now you only support first ones. And altough it's easy to overcome it via:

    xvfb = Xvfb(width=width, height=height, colordepth=depth)
    xvfb.extra_xvfb_args += ['+extension', 'RANDR', 'c', '20']

It's kinda hacky and not documented

[colllin]

I also need this to add the GLX extension, e.g. Xvfb ... +extension GLX. Another idea might be to just accept a string for the extra command-line args, i.e. Xvfb(extra_args=‘+extension GLX -noreset’)

[ranasats]

Can someone suggest how to properly supply extensions using this? Right now I have this, but I can't seem to add in +extension RANDR

   with Xvfb(width=1920, height=1080, colordepth=24, nolisten='tcp') as xvfb:
         xvfb.extra_xvfb_args += ['+extension', 'RANDR']

I still get the randr missing warning.