-
Notifications
You must be signed in to change notification settings - Fork 249
[bin-wrappers] Don't use wrappers on run #1361
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.
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
Conversation
// Prepend the bin-wrappers directory to the PATH. This ensures that | ||
// bin-wrappers execute before the unwrapped binaries. | ||
filepath.Join(d.projectDir, plugin.WrapperBinPath), | ||
// Adding profile bin path is a temporary hack. Some packages .e.g. curl | ||
// don't export the correct bin in the package, instead they export | ||
// as a propagated build input. This can be fixed in 2 ways: | ||
// * have NixBins() recursively look for bins in propagated build inputs | ||
// * Turn existing planners into flakes (i.e. php, haskell) and use the bins | ||
// in the profile. | ||
// Landau: I prefer option 2 because it doesn't require us to re-implement | ||
// nix recursive bin lookup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is in computeNixEnv
which is called in both devbox run and devbox shell.
Is this change not going to affect devbox shell?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for callers other than devbox run, the d.OmitBinWrappersFromPath
defaults to false, so this change is a no-op and hence safe for them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool!
// Prepend the bin-wrappers directory to the PATH. This ensures that | ||
// bin-wrappers execute before the unwrapped binaries. | ||
filepath.Join(d.projectDir, plugin.WrapperBinPath), | ||
// Adding profile bin path is a temporary hack. Some packages .e.g. curl | ||
// don't export the correct bin in the package, instead they export | ||
// as a propagated build input. This can be fixed in 2 ways: | ||
// * have NixBins() recursively look for bins in propagated build inputs | ||
// * Turn existing planners into flakes (i.e. php, haskell) and use the bins | ||
// in the profile. | ||
// Landau: I prefer option 2 because it doesn't require us to re-implement | ||
// nix recursive bin lookup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for callers other than devbox run, the d.OmitBinWrappersFromPath
defaults to false, so this change is a no-op and hence safe for them
## Summary While working on #1361 I noticed that we were not installing plugin packages (usually just custom flakes) to profile. This means in cases like the PHP plugin, the binary int he profile was wrong because it did not include extensions. Everything was still working as expected because bin wrappers would point to the correct binary but this is bad for 2 reasons: * We want to get rid of bin wrappers * It is quite fragile for binaries in profile to be wrong binaries This PR fixes it by ensuring plugin packages are installed. I also refactored some function names that were out of date. TODO: We currently output text when installing plugin packages that is not very user friendly. We could improve it. ## How was it tested? ```bash ➜ devbox git:(landau/install-plugin-packages-to-profile) devbox run -c examples/development/php/php8.1 php -m | grep imagick Installing dependencies from lock file (including require-dev) Verifying lock file contents can be installed on current platform. Nothing to install, update or remove Generating autoload files imagick ```
Suspect IssuesThis pull request has been deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
Summary
When doing
devbox run
the environment is always correct because commands are run in a new sub-process with correct computed environment therefore wrappers are not needed. This is a low handing fruit that should improve performance when doingdevbox run
How was it tested?