Make ServerProcess and LauncherEntry a HasTraits, update CLI flags for consistency

[jwindgassen]

As I have mentioned in #507 and #501, I do not think there is a good reason to make ServerProcess and LauncherIcon a Configurable. I like the new approach of using traitlets for these two, but ServerProxy is already a Configurable, so I think we should be fine when downgrading them to a HasTraits.

I also allowed the entries of ServerProxy.servers to be an instance of ServerProcess, so users can now do ServerProxy.servers[name] = ServerProxy(command=[...], ...) instead of using a dictionary.

[manics]

@minrk @yuvipanda do either you have time to review this? I know enough about Traitlets to work with them using trial and error, but not enough about the finer details.

[minrk]

I think this makes sense, generally.

For generic classes like ServerProcess, it doesn't make sense for values that should be unique like name to be configurable, and I like the kwarg construction which relies only on HasTraits, not specific to Configurable.

For Configurable, only common defaults really make sense in config (e.g. timeout or environment), so if there are none of those, HasTraits makes sense. If there are any, Configurable should probably be kept and instead remove config=True from the fields that don't make sense to be shared.

e.g. this PR currently removes the possibility of setting

c.ServerProcess.timeout = 10

for a common default. I'm not sure that is useful or meaningful to remove, so I'm

• +1 on using HasTraits for LauncherEntry
• +1 on removing config=True on most ServerProcess fields that don't make sense as having common overrideable defaults
• -0.5 on removing config from ServerProcess altogether, unless we determine that having user-set common defaults really doesn't make sense

[jwindgassen]

Yes, the current commit would remove the possibility to set default values to all proxies. I considered that, but IMHO it is not terribly important. We originally moved to traitlets Configurable to aid with #501. #507 even states, that this was not really meant as a new feature, especially given the fact, that setting defaults like this is not documented atm. But I can see it being a potentially useful side effect, even if I think the applications are niche.

But I can move back to Configurable and remove .tag(config=True) from all fields where it doesn't make sense. This seems like a very reasonable middle ground to me.

[minrk]

If there are common config values that make sense, let's keep them and just untag the ones that don't. But if that's not likely (especially if it wasn't intended), I've no objection to going all the way to HasTraits and removing config=True.

There really is no difference between a Configurable and a HasTraits, except for how they handle traits tagged with config=True.

[jwindgassen]

@manics @minrk This should now fix the unnecessary configurable traits of ServerProcess, as well as unify the CLI for the standalone proxy (as menioned in #501).
For the ServerProcess, I only kept the traits configurable where I thought it might be useful (environment, timeout, new_browser_tab, rewrite_response and update_last_activity). Let me know if you need anything else :)

[manics]

Thanks!