Add a --test-db global parameter to use TEST_DATABAE_URL env instead

[urkle]

The use case here is I have my local development setup where I have two databases setup, development and testing.

my .env has

DATABASE_URL=dev_url
TEST_DATABASE_URL=test_url

Currently I have a wrapper diesel-test.sh script that load the .env and switches DATABASE_URL with TEST_DATABASE_URL's contents. However this interrupts the code-completion in my shell when running changes against my test DB.

This PR adds a --test-db (-t) global parameter that will do that switch for me in the cli so I can easily switch between the two environments on the command line and still have code-completion easily.

diesel -t migration run

Outstanding issues/questions

• Can the diesel_cli::errors::Error enum be modified to allow the DatabaseUrlMissing enum to take a parameter of the ENV name? Or add a second enum for the Test URL message variant?

  #[error("The --database-url argument must be passed, or the {} environment variable must be set.")]
   DatabaseUrlMissing(String),

  or

  #[error("The --database-url argument must be passed, or the DATABASE_URL environment variable must be set.")]
   DatabaseUrlMissing,
  #[error("The --database-url argument must be passed, or the TEST_DATABASE_URL environment variable must be set.")]
   TestDatabaseUrlMissing,

  • Also shouldn't this enum be non_exhaustive?
• Right now I have it so if you specify --test-db it will NOT look at DATABASE_URL (to prevent unintended behavior if it fell back to DATABASE_URL). This seems a reasonable behavior.

[weiznich]

Thanks for opening this PR.
I'm not sure if that's the best solution as this command line flag sounds like something that fits mostly your workflow, but I do not see any discussion around whether that might be something that would benefit the majority of diesel users. I personally believe the current environment variable setup is sufficient for most of our users. I would expect that you specify the development/test url in your .env file and otherwise manually specify any overwrites as explicit argument/environment variable. That has the huge advantage that it is always explicit if you touch anything else than the default environment. Maybe you can elaborate why this isn't possible for your setup and why you believe this requires a different solution?

[urkle]

@weiznich yes I do have my DATABASE_URL setup in a .env file, however that means that will load it for one environment.

That has been the issue is that I sometimes need to switch between multiple environments (the common ones are between dev and testing). Working with other frameworks (such as the infamous ruby on rails) their CLI tools support an "environment" override param to switch between development, test, and production (or any other you create) which allows easy switching between dev & testing to work on the database.

What I have been doing thus far is I have a local script in my project named diesel-test.sh with this contents.

#!/bin/sh

. .env
export DATABASE_URL=$TEST_DATABASE_URL

diesel "$@"

However this did not have tab-completion thus making it harder to use on the command line (I live on the CLI).

Digging in some more I found an alternative that accomplishes the same as what this PR provides by doing this.

1. create a diesel-test script in my ~/bin (in my $PATH)

   #!/bin/bash
   
   if [ ! -f .env ]; then
       echo "Run in the directory containing a .env with a TEST_DATABASE_URL env"
       exit 1
   fi
   
   . .env
   
   if [ -z "$TEST_DATABASE_URL" ]; then
       echo "No TEST_DATABASE_URL defined in .env"
       exit 1
   fi
   
   export DATABASE_URL=$TEST_DATABASE_URL
   
   diesel "$@"

2. in my bash_completion setup I added this line to configure this new script to have the same alises

   complete -F _diesel -o nosort -o bashdefault -o default diesel-test

I may fiddle more with that diesel-test script as another alternative approach would be to have it load the env from .env.test (e.g. load .env then load .env.test) and having that built-into the diesel cli might be night.. e.g. a -e test or whatever name you want and have it load (via dotenv) the .env.test and the main .env (defaulting to load .env.dev?) this is the way many other tools in other frameworks load things up to allow env-specific override file. (vite does this, php tooling I've used does it, the rails frameworks do.)

[weiznich]

Thanks for providing these details. I think I now understand at least the problem that you are trying to solve. I'm still not sold on the implemented approach.

another alternative approach would be to have it load the env from .env.test (e.g. load .env then load .env.test) and having that built-into the diesel cli might be night.. e.g. a -e test or whatever name you want and have it load (via dotenv) the .env.test and the main .env (defaulting to load .env.dev?) this is the way many other tools in other frameworks load things up to allow env-specific override file. (vite does this, php tooling I've used does it, the rails frameworks do.)

That sounds like a much better solution. I would be open to accept a PR that implements such a flag, so that the prefix is used while loading .env files and optionally to prefix the environment variables (so for -e test first try TEST_DATABASE_URL and only if that not exists DATABASE_URL).