fix(macros-core): more consistent env loading and reading logic #4018
+98
−50
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While giving the new `sqlx.toml` feature a try, I discovered that its `database_url_var` setting behaved inconsistently compared to other environment variables: it wasn't loaded from `.env` files, causing it to be effectively ignored in favor of the default `DATABASE_URL` variable. This is an inconvenient outcome for the multi-database workspaces that this feature is designed to support. To address this issue, I reworked the `.env` loading logic to account for this configuration and make it simpler to use to achieve consistent behavior. The new algorithm works as follows: - First, it generates lists of environment variables that can be loaded from `.env` files and candidate `.env` file paths. When applicable, the compiler is informed to track changes to their elements. - Next, it loads the set of potentially tracked environment variables using `set_var`, similar to how `dotenvy::dotenv()` operates. When a variable is defined in both the process environment and a `.env` file, the process environment takes precedence, as before. - Macro code can now use the `env` function freely to read environment variable values, abstracting itself away from their source, which results in simpler, less error-prone code. Trivially, this rework resolves the issue I encountered because the `database_url_var` value is now part of the list of loadable environment variables. Future code can easily make such additions as necessary.
AlexTMjugador
force-pushed
the
fix/consistent-macro-env-handling
branch
from
a8a9e0c to
89858d7
Compare
jplatte
reviewed
Sep 5, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context, problem statement and description
While giving the new
sqlx.tomlfeature a try, I discovered that itsdatabase_url_varsetting behaved inconsistently compared to other environment variables: it wasn't loaded from.envfiles, causing it to be effectively ignored in favor of the defaultDATABASE_URLvariable. This is an inconvenient outcome for the multi-database workspaces that this feature is designed to support.To address this issue, I reworked the
.envloading logic to account for this configuration and make it simpler to use to achieve consistent behavior. The new algorithm works as follows:.envfiles and candidate.envfile paths. When applicable, the compiler is informed to track changes to their elements.set_envwas used, but I changed it as a response to the review comments below). When a variable is defined in both the process environment and a.envfile, the process environment takes precedence, as before.envfunction freely to read environment variable values, abstracting itself away from their source, which results in simpler, less error-prone code.Trivially, this rework resolves the issue I encountered because the
database_url_varvalue is now part of the list of loadable environment variables. Future code can easily make such additions as necessary.Does your PR solve an issue?
To my knowledge, this PR doesn't directly address any previously reported issue in this repository.
Is this a breaking change?
Technically yes when compared to the released
0.9.0alpha version, as environment variables likedatabase_url_varmay now be loaded from another source. However, I don't think this technically breaking change will cause significant inconvenience for most users, especially since the new behavior is more consistent and useful, and the affected variables are bound to not be widely used due to them being published as an alpha release so far.