WIP hab: support multiple idents and build vars in `hab pkg env`

[stevendanna]

This allows the user to run commands such as

hab pkg env core/make core/gcc

The printed environment will contain the merged environment for certain well-known variables. For unknown variables, the first package to include the variable wins.

The --build flag now allows the user to print the build-relevant environment variables for the given packages.

The --append-existing flag appends any existing values of the relevant environment variables from the processes environment to the printed environment.

Together, these features allow us to create ad-hoc development environment using Habitat packages, which is nice for when developing software locally:

eval "$(hab pkg env core/gcc core/glibc core/openssl --build --append-existing)"

This is especially nice when trying to go through the edit-compile-debug loop using local tools. In such a case a full habitat package build is often slow without special code inside your plan.sh specifically for dev builds.

If we are interesting in pursuing this, I think that to make this most useful the path forward might look like:

• Review and exactly define the semantics of how variables are merged, build vs runtime variables, and transitive vs non-transitive dependencies.

• Rewrite some of the code in hab-plan-build to use this command directly so that we have only 1 implementation of this code.

Signed-off-by: Steven Danna [email protected]

[chef-expeditor[bot]]

Hello stevendanna! Thanks for the pull request!

Here is what will happen next:

1. Your PR will be reviewed by the maintainers.
2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

[stevendanna]

This is an old branch I had around. I was wondering if a feature like this is something other people would be interested in.

Really, this is just an experiment in features we can build into hab to start making it better as a local development environment. Right now the studio is heavily optimized for building 3rd party software that you don't have to substantially edit. I think in the long run there is probably a constellation of features we would like to work on if that is a use case we'd like to cover.

[christophermaier]

This seems like a useful addition; I also like the fact that it would eventually allow us to move the build logic out of Bash.

Any thoughts @smacfarlane ?

[smacfarlane]

This looks really awesome @stevendanna.

I haven't read too closely (yet) and compared to plan-build, but I wonder if this would benefit from being behind a feature flag or some other way of signalling this is an area of active exploration and may change as all of our thoughts and/or use cases haven't crystallized yet?

I haven't entirely convinced myself that that would be necessary, but this feels like the tip of a very cool iceberg and we may need to change the shape of things as we iterate.

[stevendanna]

but I wonder if this would benefit from being behind a feature flag or some other way of signalling this is an area of active exploration and may change as all of our thoughts and/or use cases haven't crystallized yet?

I think this is probably worth doing if for no other reason than to let us use the behavior for a bit and see if it is right.

[stale[bot]]

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.

[stale[bot]]

This issue has been automatically closed after being stale for 400 days. We still value your input and contribution. Please re-open the issue if desired and leave a comment with details.