Skip to content

[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

Merged
merged 4 commits into from
Aug 11, 2023
Merged

Conversation

mikeland73
Copy link
Contributor

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 doing devbox run

How was it tested?

➜  devbox git:(main) ✗ devbox run which go
/Users/mike/dev/jetpack-repos/devbox/.devbox/nix/profile/default/bin/go
➜  devbox git:(main) ✗ devbox shell
Starting a devbox shell...
(devbox) ➜  devbox git:(main) ✗ which go
/Users/mike/dev/jetpack-repos/devbox/.devbox/virtenv/.wrappers/bin/go

@mikeland73 mikeland73 requested review from savil and mohsenari August 10, 2023 04:49
Comment on lines -835 to -858
// 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.
Copy link
Collaborator

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?

Copy link
Collaborator

@savil savil Aug 10, 2023

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

Copy link
Collaborator

@savil savil left a comment

Choose a reason for hiding this comment

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

cool!

Comment on lines -835 to -858
// 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.
Copy link
Collaborator

@savil savil Aug 10, 2023

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

mikeland73 added a commit that referenced this pull request Aug 11, 2023
## 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
```
@mikeland73 mikeland73 merged commit 0466f6a into main Aug 11, 2023
@mikeland73 mikeland73 deleted the landau/no-wrappers-on-run branch August 11, 2023 23:43
@sentry-io
Copy link

sentry-io bot commented Aug 13, 2023

Suspect Issues

This pull request has been deployed and Sentry observed the following issues:

  • ‼️ *syscall.Errno: error reading devbox.json: <redacted fs.PathError>: go.jetpack.io/devbox/internal/boxcli in runScri... View Issue

Did you find this useful? React with a 👍 or 👎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants