data-dir argument and hg-name option

[nvictus]

Description

1. Someone types higlass-manage start and expects to see help text because they're too lazy to type --help, but instead it pulls a 2GB docker image and runs a container in a directory that isn't advertised.

2. It's not obvious what options are needed to run multiple instances.

What was changed in this pull request?

• higlass-manage start requires a data directory as argument
• Make name, and port the first 2 options to higlass-manage start
• Make -n, --hg-name a consistent option to all relevant commands.
• Change ingest --name to --display-name
• Turn version into an option.
• Some code formatting.

Why is it necessary?

A command with no arguments shouldn't have side-effects.

Fixes #___

Checklist

• Unit tests added or updated
• Documentation added or updated
• Updated CHANGELOG.md

[nvictus]

If we want to have a default user directory for the default container, I would propose having it in a namespace like ~/.higlass/containers. Still, it shouldn't launch without some kind of input to the start command.

[nvictus]

Though, an alternative could be to provide a confirmation prompt when no input is passed...

[pkerpedjiev]

TLDR: I agree with the premise but not the solution.

Specifically, I don't think that higlass-manage start should necessarily require parameters. We should have sensible defaults.

Someone types higlass-manage start and expects to see help text because they're too lazy to type --help, but instead it pulls a 2GB docker image and runs a container in a directory that isn't advertised.

I don't know about others but I always type --help when I want to see the options for a command. It sounds to me like the solution here is to advertise the directory that it has started in.

It's not obvious what options are needed to run multiple instances.

This is a documentation issue that should be cleared up using --help. Making people enter arguments just makes using higlass-manage more frustrating. Parameters should serve to enable, not compel.

A command with no arguments shouldn't have side-effects.

Most services start up just fine with no arguments. Examples: sudo /etc/init.d/nginx start, docker-compose up. While they may require some init file, it is not uncommon to install a service and start it with one command. They have default data directories and ports that can be modified with extra arguments. Database systems come immediately to mind.

If we want to have a default user directory for the default container, I would propose having it in a namespace like ~/.higlass/containers

I think that's fine.

Still, it shouldn't launch without some kind of input to the start command.

See point #1.

We still need a default though. For example, the command I use by far and away most often is higlass-manage view some_file. This needs to start in a default directory.

[nvictus]

Yeah, I see the point about having a default directory and about service launchers. I think namespacing ~/.higlass/ would also let us introduce an rc file in there to customize command line defaults.

I would propose then for start:

• print what is happening (starting container "default" in {location})
• prompt the user if the target directory (default or otherwise specified) does not exist so they can abort if they disagree... there can be a option to override prompts, of course, if not working interactively.

[pkerpedjiev]

I would propose then for start:

print what is happening (starting container "default" in {location})
prompt the user if the target directory (default or otherwise specified) does not exist so they can abort if they disagree... there can be a option to override prompts, of course, if not working interactively.

That sounds sensible 👍

[nvictus]

Okay, I reverted the data_dir argument back into an option and added a confirmation prompt if it doesn't exist.

I also changed the default directory to $HOME/.higlass/containers/{hg_name}.