Chris Flipse wrote:> Pardon the crosspost, but this applies to both
>
> So, at work, I''m one of several people developing on the same
> multi-user unix system. I/we would like to be able to use the drb
> server, but at the moment rspec,cucumber and spork assume a single
> well known port number for drb. That doesn''t work well on a
> multi-user system.
>
> My itch, and I''m starting to look through the codebases to scratch
> it. I''m planning on patches for spork and cucumber as well.
>
> There are two ways I can see to implement this, just wanted to see
> what people thought about it. The first is through an environment
> variable, and the second is through adding command line switches.
>
> adding the switches to the command lines seems like it will be more
> invasive, and it would require people to remember to specify the port
> on any manual invocations. Also need to pass the right port in to
> your spork invocations. On the other hand, it''s more consistant
with
> the way the rest of the options are specified, and could be set in an
> indivudual user''s cucumber.yml or spec.opts, mitigating the
command
> line issue (though, frequently, I don''t use my spec.opts file)
>
> setting an environment variable, say RSPEC_DRB or CUCUMBER_DRB would
> be much less invasive, since the main codebases specify their global
> drb ports through a constant anyway. It''d be fairly easy to have
them
> check for an environment variable before accepting the default.
I''d
> just have to add the ability to specify a specific port to spork.
> Downside is that it''s not as consistant with the rest of the
> configuration. Upside from a user perspective is that it''s
completely
> fire-and-forget; just set an env variable in your .profile, and
you''re
> done worrying about it...
>
>
> Thoughts?
>
I can see where you are coming from and understand the tradeoffs... It
would be nice just to set an ENV var and have both cucumber and spork
operate on it. It does feel a little dirty though and could result in
confusion if they were ever misspecified. It is also harder to document
the use of constants, whereas the the options already have a
convention. For the sake of consistently I would rather see them be
specified using options. Does anyone else have a preference or argument
for using env vars?
BTW, thanks for doing this. :)
-Ben