> > >> I disagree, this would be totally expected behavior. The daemon and this >> process would run in different shells and I am unaware of any daemon >> process that auto-magically reconfigures it’s self to adapt to any other >> arbitrary shell’s changed environment variables. > > The thing is that the daemon is an "implementation detail". The user doesn't even need to know there's one. It's here for performance reasons. If we could get the same level of performance, and startup time, right from the process start, there wouldn't be any need for a daemon. But the truth is different: with classloading, in-memory dependency management caches, and the JIT, the daemon is required. So imagine the surprise if a user just does a "cd subproject" and start Gradle, and we spawn a new daemon, just because the "PWD" environment variable has changed. It doesn't make sense. Also it can lead to surprising behaviors: if you run 2 builds concurrently (this happens, yes, we have thousands of users so all scenarios exist in the wild), then depending on whether the daemon was busy when you start the build, you would get different environment variables: the busy one would get the environment variables when it was started, and the fresh one to run the 2d build would get the refreshed ones, because started at a different point in time.
Another scenario: one might think (we do) that it's better to use project properties than environment variables to communicate runtime specific configuration. But the reality is always more complex. For example, our build scripts may require calling a Perl library at some point (imagine, for example, calling FlameGraph). If that library is configured through environment variables (say, it requires FLAMEGRAPH_HOME to be set), then it's better to check beforehand if the environment variable is set, rather than executing the build and failing when we try to call it. So, the build script needs to check that this environment variable is set. If we don't propagage the client environment variables to the daemon, then 2 things happen: 1. the check to verify that the environment variable is set would fail, even if it has been set in the CLI 2. we wouldn't be able to set the environment variables of the forked process running Perl to the appropriate set of variables
