sbtn should reevaluate env variables

[agilesteel]

steps

Given a hello world application that reads out an environment variable and prints it out:

@main def Main(args: String*): Unit =
  println(System.getenv("FOO"))

Then run:

FOO=BAR sbtn run

problems

I see null.

expectations

I see BAR

notes

When I run:

FOO=BAR bloop run my-project

I correctly see BAR

In fact the sbtn behavior is flaky. It depends on how the server was started. If the server was not running to begin with, then yes

FOO=BAR sbtn run

will indeed print out BAR and the subsequent requests as well. However as soon as we change it to

FOO=NOT_BAR sbtn run

we will keep seeing the incorrect BAR.

original report

I'm not sure whether it's an issue or a feature request. I already created a feature request here: https://discuss.lightbend.com/t/feature-request-sbtn-should-reevaluate-env-variables/9908 but haven't heard anything in over 2 weeks so I'm opening an issue here as well.

[laughedelic]

I think this issue is related:

• sbt --client ignores other flags or SBT_OPTS #6468

[eed3si9n]

I don't monitor Lightbend forums since I no longer work there. We have https://github.com/sbt/sbt/discussions for discussions, but I'm happy to discuss this issue/feature here.

[agilesteel]

Yeah no worries @eed3si9n it's just that submitting a feature request here points to the Lightbend forums which is why I submitted it there.

So is this a bug or a limitation of the current implementation?

[SethTisue]

it's just that submitting a feature request here points to the Lightbend forums which is why I submitted it there.

ahhhh, https://github.com/sbt/sbt/blob/1.8.x/.github/ISSUE_TEMPLATE/--feature-request.md needs updating, thanks for bringing that up. @eed3si9n I guess you know best what URL and wording you want

[eed3si9n]

Thanks both. I've fixed the issue template 5bd4405.

So is this a bug or a limitation of the current implementation?

It's hard to say. Strictly speaking, as sbt, this is working as intended because sbt emulates run (JVM process) using a function call reusing the JVM already started by sbt server.

However, the spirit of sbtn is to make it work seamlessly with the shell environment (bash, zsh etc) so your expectation also makes sense as the future direction of sbtn. Somewhat related:

• https://www.scala-sbt.org/1.x/docs/Running-Project-Code.html
• https://www.scala-sbt.org/1.x/docs/In-Process-Classloaders.html
• https://www.scala-sbt.org/1.x/docs/Forking.html

A feature that I've always wanted is letting individual client like sbtn execute the program when run is requested (#6178), which should largely solve this problem of env variable inheritance.