Feature Request: Add optional debug=port parameter

[S-Kantor]

Hi,

My regular development flow when working on debugging services follows something like this.

1. Set up remote debugger to port y
2. Open ~/repo/edward.json
3. Find my service and add --debug y inside the launch step
4. Close the file, and edward start service
5. Then when I'm done my debugging, I have to manually revert my changes to edward.json.

If it's possible, I think something like this would be more ideal.

edward start service debug=y

The benefits of this change:

• No accidental edward changes getting committed to source
• Less manual efforts
• A model that can allow for other optional parameters passed in to edward start/restart service

[theothertomelliott]

I know of plenty of people who'd find this useful!

Can you think of a way to structure it so we could add different flags? For example, I could see it being useful to add log leveling flags to some services, or specify a different port.

[S-Kantor]

After looking through our edward.json file, I think I might have a good solution.

If we only want to support adding flags to the launch step, I believe we could structure it as follows:

edward (re)start service options=["--config=value", "--config2 value2", "config3 value3", "config4=value4", etc.]

The rationale here is that options can be supplied in a variety of ways depending on the program. Some might make their options be accessed with --option or option and setting option values could be supported through = or through . (i.e. config3/config4 above).

Since every application is different, and the user who is changing them knows how the options should be supplied (as that's what they had to manually change in edward.json), they should provide the syntax for the options at runtime. The quotes are important as edward will just append each option as is and a space which will keep the implementation relatively simple.

With the above structure, we save developer time by allowing them to dynamically change what options they are starting their service with, as well as saving edward development complexity by not having to worry about the complexity that comes with determining how to supply options to go/java/docker programs at runtime.

If we want to support adding flags to all of steps/commands (i.e. build/launch/stop/etc), I believe we could structure it as follows:

edward (re)start service command1_options=["--config=value", "--config2 value2"] command2_options=["config3 value3", "config4=value4"]

I.e.
edward start service launch_options=["--config=value"]

Edward will parse out the command1/command2 and associate the options to their respective steps.

[theothertomelliott]

Nice! This could also be represented as something like:
launch_option="--config=value" launch_option="--config2=value2"

How would we determine the position in the launch command where we would inject the options? Some flag parsers require specific flags to appear before a command or argument.

[S-Kantor]

That definitely looks cleaner, but I worry that as the number of options passed in rises, users may not appreciate having to retype launch_option each time. What do you think?

Re: How to determine where to inject options?

I think a fair solution to this would be to make it as intuitive to users as we can. I believe we should place the options from left to right as they were written in the options array.

If the flag parser required a flag to appear before another one, edward would print the error message and the user who entered the command will know that they have to move the options around immediately. They will figure out the order from the error message. Users can be confident that the order of which the options were written out in, will be the same order edward will pass the options to the program.

If we tried to solve it any other way and got the automatic re-ordering wrong, then users will have a bad experience. They will be able to move the options around, but because of our automagic re-ordering rules, edward will still supply the options in the same incorrect re-order.

Moreover, it's pretty difficult to come up with option re-ordering rules as different programs/ flag parsers have their own specific rule set, and what may work for one set of programs may not work for another.

[theothertomelliott]

The ordering problem isn't limited to the parameters the user is entering. For example:
launch: "fileserver path/to/files"
Could represent a simple file server service. To set the debug level, you'd need to run: fileserver --log=DEBUG path/to/files
Appending the log flag would result in an error. How might we control that positioning?

[S-Kantor]

That's a pretty difficult problem.

The way that i see it is that, the current launch path already has an arbitrary number of parameters.
I.e. $A1 $A2 ... $AX

We want Edward to support injecting an arbitrary number of parameters.
I.e. $B1 $B2 ... BY

Which means we want edward to be able to generate combinations that look like

1. $A1 $B2 $B3 $A2
2. $A1 $B3 $B2 $A2
3. $A1 $B3 $A2 $B2
   Etc.

The problem that I'm having is that it's hard to figure out what kind of assertions I can make about the parameters. I.e. If $A2 is a file or directory, then can I be certain that $B2 which a log command must be inserted before $A2 always?

Do you have any advice on how to come up with these kinds of assertions?

[theothertomelliott]

The problem space for all possible command structures is pretty large, so I think we might be making a rod for our own back if we try to create specific "rules" around where to put types of parameters.

What if the person creating the edward config could specify where to put particular params? Then if you need to add a param in the edward.json file to support debugging, you can commit your change to make the next person's life easier.

[S-Kantor]

That's a pretty neat approach!

How would you recommend someone add a param?

If I'm understanding the approach correctly, in the launch step we could have something like:

launch: server --log=default_value //path/to/files and if the user supplied a "log" option, then edward would replace default value with the user-supplied option.

However, I'm curious about how we should structure the default_value? One thought I had would be to have a null value like __ that edward could detect and remove the option entirely. That way if someone added a --debug=__ param to the step, the entire config would get stripped by edward.

[theothertomelliott]

Going in the right direction, but I think we may need to wrap the whole option, since some flag parsers only allow "-d __" or "--debug __" without the = to join them together.

We probably need something to wrap the whole placeholder, like:

launch: "server {{--log=$VALUE}} //path/to/files"