Habitat: fix_interpreter is not available for build/check tools

Created on 6 Jul 2016  Â·  4Comments  Â·  Source: habitat-sh/habitat

In a given package, the make check includes a shell script to run all included tests.
The script has a shebang pointing to /usr/bin/env.

I tried to fix it with fix_interpreter, but since fix_interpreter applies only to interpreters found in pkg_deps, it fails with:

[6] re2c(do_check)> fix_interpreter "$pkg_prefix/run_tests.sh" core/coreutils bin/env
   re2c: WARN Could not resolve the path for core/coreutils, is it specified in 'pkg_deps'?
   re2c: WARN fix_interpreter() 'core/coreutils' is not a runtime dependency
   re2c: WARN Only runtime packages may be used as your interpreter must travel
   re2c: WARN with the 're2c' in order to run.
   re2c: WARN Resolved runtime package set: /hab/pkgs/core/gcc-libs/5.2.0/20160612075020
[7] re2c(do_check)>

This leads to the following pattern, which is less awesome:

do_prepare() {
  # The `/usr/bin/env` path is hardcoded in tests, so we'll add a symlink since fix_interpreter won't work.
  if [[ ! -r /usr/bin/env ]]; then
    ln -sv $(pkg_path_for coreutils)/bin/env /usr/bin/env
    _clean_env=true
  fi
}

do_check() {
  make check
}

do_end() {
  # Clean up the `env` link, if we set it up.
  if [[ -n "$_clean_env" ]]; then
    rm -fv /usr/bin/env
  fi
}

Instead of being the shorter version of:

do_check() {
  fix_interpreter "$pkg_prefix/run_tests.sh" core/coreutils bin/env
  make check
}
Studio S-needs-discussion Bug

All 4 comments

So is the issue that you need fix_interpreter to honor pkg_build_deps as well?

I think that would work, yes.

On Wed, Jul 6, 2016, 12:44 Adam Jacob [email protected] wrote:

So is the issue that you need fix_interpreter to honor pkg_build_deps as
well?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/habitat-sh/habitat/issues/1041#issuecomment-230832652,
or mute the thread
https://github.com/notifications/unsubscribe/AAgUbLhnLpoQ_oEctkZsgWoA00vG5gk6ks5qS9tjgaJpZM4JGFW6
.

I can see the danger in this approach - any use of fix_interpreter for a build dep could possibly be abused incorrectly - as the log warning states Only runtime packages may be used as your interpreter must travel - which is what you'd want in the general use case.

An alternate approach may be a fix_build_interpreter or similarly named function that allows the pkg_build_deps to be used. Likely very similar code, with a bit of conditional handling for build vs non-build, allowing both approaches to be valid, and retaining a self-documenting function name that conveys intent, and possibly warns if used on a pkg_deps value.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

Was this page helpful?
0 / 5 - 0 ratings