Configurable project name via composition option about arion HOT 13 CLOSED

got this error too

arion \
        --file docker/db_tests_dev.nix \
        --pkgs nix/pkgs.nix \
        --project-name "myproj_db_tests_dev" \
        run --rm migrator sh -c '\
                asdfasdfasdfadsf'

returns

Invalid option `--project-name'

and

arion \
        --file docker/db_tests_dev.nix \
        --pkgs nix/pkgs.nix \
        -p "myproj_db_tests_dev" \
        run --rm migrator sh -c '\
              asdfasdfasfd'

returns

Invalid option `-p'

Did you mean one of these?
    -f
    up
    top
    rm
    ps
    -h

Usage: arion [-f|--file FILE] [-p|--pkgs EXPR] [--show-trace] [--nix-arg ARG]
             (COMMAND | DOCKER-COMPOSE-COMMAND)

had to rollback to cc9e70a

from arion.

yes, I need it as command line option (I think)

from arion.

The issue is that not all compose arguments are duplicated in form of env variables

Options:
  -f, --file FILE             Specify an alternate compose file
                              (default: docker-compose.yml)
  -p, --project-name NAME     Specify an alternate project name
                              (default: directory name)
  --verbose                   Show more output
  --log-level LEVEL           Set log level (DEBUG, INFO, WARNING, ERROR, CRITICAL)
  --no-ansi                   Do not print ANSI control characters
  -v, --version               Print version and exit
  -H, --host HOST             Daemon socket to connect to

  --tls                       Use TLS; implied by --tlsverify
  --tlscacert CA_PATH         Trust certs signed only by this CA
  --tlscert CLIENT_CERT_PATH  Path to TLS certificate file
  --tlskey TLS_KEY_PATH       Path to TLS key file
  --tlsverify                 Use TLS and verify the remote
  --skip-hostname-check       Don't check the daemon's hostname against the
                              name specified in the client certificate
  --project-directory PATH    Specify an alternate working directory
                              (default: the path of the Compose file)
  --compatibility             If set, Compose will attempt to convert deploy
                              keys in v3 files to their non-Swarm equivalent

COMPOSE_API_VERSION
COMPOSE_CONVERT_WINDOWS_PATHS
COMPOSE_FILE
COMPOSE_HTTP_TIMEOUT
COMPOSE_TLS_VERSION
COMPOSE_PROJECT_NAME
DOCKER_CERT_PATH
DOCKER_HOST
DOCKER_TLS_VERIFY

For example --compatibility

One possible way to resolve this would be to add compose prefix to all arguments

Like --compose-p, --compose-project, --compose-compatibility

from arion.

Hi @srghma,

The option parsing was reworked in the latest merge. I wasn't aware that the project name feature was already usable.

My intent for this feature was to make it configurable in arion-compose.nix.

To support your use case we'll have to add a command line option to define values in the composition config.

from arion.

Let me share my thoughts :)

Yes, this functionality should be available. However, the proposed implementation conflicts with my goal to simplify the interface compared to docker-compose.

Design goal

Like any piece of software, docker-compose comes with some baggage. I'd like to avoid copying all of that, especially where we have better alternatives due to Nix.

One of the problems with docker-compose is having to deal with a multitude of separate configuration states, specifically:

• the docker compose files
• any environment files
• the process environment
• command line arguments

These can not be assumed to be interchangeable.

So for someone who is learning arion and does not have much knowledge about docker-compose, I don't think we should require them to learn all of that.

Instead of having configuration spread sparsely across a locations × configurations matrix, I'd like to have all locations map to a single "namespace" of configurations.

So what are the locations we do want to have?

• arion-compose modules
  • generic ones, following the typical meaning of "module" in Nix
  • concrete ones, usually called configurations, importing other modules
• environment variables are available through Nix if necessary, but also in docker-compose literal strings. The latter will be disabled (escaped) by default. They're confusing. These seem to be unavoidable and can serve a role in secrets deployment. I'd recommend against using these for configuration.
• command line arguments to try things out quickly and for things that are truly transient like --log-level, or to inject values easily --option-string name=myproject

All of these should be able to set everything including things that are command-line only, like the project name. The project name should be set in a "concrete" arion compose configuration, as defined above.

Implementation

Now that we know where arion is supposed to go, we can figure out the steps to get there.
To address your concern about the availability of (potentially new?) docker-compose command line options, we have a conflict to resolve with the design as above.
This can be address by dividing the problem into known and unknown options.

The known options will have only arion-compose options. Unknown options will be passed via --docker-compose-arg=--new-thing --docker-compose-arg=arg-for-new-thing.

Proper command line options can be added for these, which will not have options:

• verbosity
• log level
• ansi

Docker-compose command line options that have arion-compose.nix options will be forbidden or warned about when set via --docker-compose-arg. They should be set with --option-string name=myproject for example.
--project-directory will be forbidden entirely. All path handling must happen through nix.

from arion.

ok, I see
having project-name in nix file works for me too

from arion.

@roberth hi, what's the status of this issue?

from arion.

Worked around it last week to keep focus, but it's time to implement it. Doesn't seem like a lot of work

from arion.

@srghma what do you think of #104?

from arion.

Thx! That would work

Except I think the name project name is better than name

And how about other compose options?

#54 (comment)

I don't need them for now, though

from arion.

I've renamed it to project.name and added support for --no-ansi, --compatibility, --log-level options.
Most of the other ones are better managed as environment variables for now, because they can be security sensitive and the docker compose file is written to the Nix store which is not intended for confidential info.
Support for other module options and command line options can be added later.

from arion.

tnx a lot!

from arion.

In case it helps future readers, I was looking for a way to specify the project name from the command line.
With docker-compose, that looked like:

docker-compose -p "yourProjectName" up

And with arion, that looks like:

COMPOSE_PROJECT_NAME="yourProjectName" arion up

Re-reading this thread, I see that was already explained above, but it took me a while to work that out.

from arion.