Skip to content

[env] Fixed env_from bug when it is called from a subdirectory #2355

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Oct 16, 2024
Merged

[env] Fixed env_from bug when it is called from a subdirectory #2355

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
9336afa
Fixed env_from bug when it is called from a subdirectory
mohsenari Oct 15, 2024
b4045af
Handled the case where env path is absolute
mohsenari Oct 15, 2024
6dbef33
error out if env_from is absolute path
mohsenari Oct 15, 2024
24caaf8
Lint fix
mohsenari Oct 15, 2024
cbf49a0
Allowing absolute path for env_from
mohsenari Oct 16, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions internal/devconfig/configfile/env.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ package configfile
import (
"fmt"
"os"
"path"
"path/filepath"

"github.com/hashicorp/go-envparse"
Expand All @@ -25,10 +26,15 @@ func (c *ConfigFile) ParseEnvsFromDotEnv() (map[string]string, error) {
if !c.IsdotEnvEnabled() {
return nil, fmt.Errorf("env file does not have a .env extension")
}

file, err := os.Open(c.EnvFrom)
envFileAbsPath := filepath.Dir(c.AbsRootPath)
if filepath.IsAbs(c.EnvFrom) {
envFileAbsPath = path.Join(envFileAbsPath, path.Base(c.EnvFrom))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this scenario be envFileAbsPath = c.EnvFrom?

if the user has set

// devbox.json
{
   "env_from": "/my/absolute/path/foo.env`
}

Then, I'd think we want to just obey the absolute path directive.

Perhaps we should error if the env_from path is absolute, because that would mess up any reproducibility of the devbox.json config. But I'll be open to just letting it fly. We can expect our users to use their judgement for when they want to make their config a bit less reproducible. For example, for the sake of some quick changes they may want to experiment with.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the absolute path erroring out case. Reproducibility should be considered here. I'll push a commit to change this case to an error.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We allow absolute paths for flakes and plugins. I don't think env should be different. Absolute paths can be important for reproducibility as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it even more, I don't think relative paths are any more reproducible than absolute paths! relative paths are more reproducible only if .env file is in the repo, but in that case you are better off just adding to the env field in devbox.json

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikeland73 the idea is to prevent unintended mistakes that comes with putting absolute paths. For example, if user A puts /Users/A/projects/Aproject/.env and user B has the repo clone in /Users/B/... it will break the reproducibility.
Do you think this is an acceptable risk and we should allow absolute path here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 reasons:

  • erroring on abs path is not backward compatible. This reason alone is a blocker. path of least resistance is always to preserve backward compatibility, especially if it's easier!
  • relative poths also allow you to make it non reproducible! ../path/to/my/.env would also live outside the repo. Or just .env when .env is in gititnore.

Why would folks use this feature with .env file that is checked in to their repo? (I guess some convenience maybe, but seems low value). The use case for this feature is for people to have different .env files, so by definition reproducibility is not as important.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this logic at all. Why would the path of the config matter?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was handling the case when env_from was absolute. Your suggestion below works too, it's just handling if abs() vs if !abs()

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If env_from is absolute you don't need to change it at all.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I agree, I overcomplicated the logic there.

} else {
envFileAbsPath = path.Join(envFileAbsPath, c.EnvFrom)
}
file, err := os.Open(envFileAbsPath)
if err != nil {
return nil, fmt.Errorf("failed to open file: %s", c.EnvFrom)
return nil, fmt.Errorf("failed to open file: %s", envFileAbsPath)
}
defer file.Close()

Expand Down