Non-expected behaviour when using specific env in tests and not forking

[albertpastrana]

Hey, first of all, thanks for your project, we are using extensively and it's super useful to us.

We have lately faced a strange problem when trying to specify a specific environment file for the tests. It looks like those environment variables will only be picked if you set the fork in tests to true.

As it's a bit difficult to explain, I've created a sample project that illustrates the problem we are having https://github.com/albertpastrana/sbtenv-fork-test

Hope that helps

[Philippus]

@slavaschmidt do you have any ideas around this? Is this a limitation or is this something we can fix?

[slavaschmidt]

@Philippus, I believe in general forking should not be needed.

The test case can be fixed by defining the environment as following:

envFileName in ThisBuild := "test.env"
envVars in Test := (envFromFile in Test).value

I think there is a combination of following factors in play in this case:

• The fact that the plugin tries to load ".env" file by default here: https://github.com/mefellows/sbt-dotenv/blob/600a931b7731ebb398901ebe198649ed65135f07/src/main/scala/au/com/onegeek/sbtdotenv/SbtDotenv.scala#L55
• During test run It will load and apply another file as defined for Test, the "test.env"
• Without forking this will happen in the same process
• I'm not 100% sure what exactly happens then but one of the following might be a problem: a) it is not possible to load native library more than once in the same JVM; b) the native library creates a "copy" of the system environment and modifies it and doing this twice, once per environment file, might have unpredictable results

With this reasoning I see possible solutions:

• forking (as demonstrated by the test case)
• loading the configuration only once (as demonstrated by overriding the env file name in ThisBuild at the beginning of this comment)
• I believe another option could be to add some possibility to suppress the loading of the default environment

Maybe it makes sense to debug how the native library related part behaves and modify it if possible to allow multiple applications in single / current process.