add: extension env-injector

[locnnil]

• Have you followed the guidelines for contributing?
• Have you signed the CLA?
• Have you successfully run tox run -m lint?
• Have you successfully run tox run -e test-py310? (supported versions: py39, py310, py311, py312)

---

Add extension to inject environment variables into snaps by its command-chain.
This extension takes snap options and transform them into environment variables

[farshidtz]

Thanks, I've tested and everything works as expected.

I have a few concerns, on the testing, error handling, and documentation.

[farshidtz]

Thanks for the fixes.
I've just discovered another issue while testing.

[farshidtz]

Looks good. Thanks a lot.

Nevertheless, I do have concerns over the licensing of snaps using this extension. The extension adds a binary distribution to the snap which uses the following libraries:

• https://crates.io/crates/dotenv (MIT)
• https://docs.rs/http-body-util/latest/http_body_util/index.html (MIT)
• https://github.com/hyperium/hyper (MIT)
• https://github.com/hyperium/hyper-util (MIT)
• https://github.com/softprops/hyperlocal (MIT)
• https://github.com/serde-rs/serde (Apache 2.0 or MIT)
• https://docs.rs/serde_json/latest/serde_json/ (Apache 2.0 or MIT)
• https://github.com/tokio-rs/tokio (MIT)

We need to take a deeper look into this before flagging the extension as stable. I believe a snap using this extension needs to list MIT as one of its licenses and bundle a copy of the license files for all the above. A simpler solution would be to go back to the Bash implementation (at the expense of performance) with a royalty-free license such as CC0.

[mr-cal]

Overall, I think the extension and spread test look good, but I'm not sure how it will work without a configure hook.

Also, this will need a tests/unit/extensions/test_env_injector.py.

I would like to return to one of the original criteria. We still need a snapcraft.io forum post about this idea to get input and feedback on this approach. We can adjust this PR so it gets published to a branch for testing.

[farshidtz]

@mr-cal

I would like to return to one of the original criteria. We still need a snapcraft.io forum post about this idea to get input and feedback on this approach. We can adjust this PR so it gets published to a branch for testing.

We have done extensive research on the existing practices. The plan was to get this added as an experimental extension to allow widespread testing (assuming this is the whole point of experimental extensions) and validate the proposed configuration schema for the snap options keys. A forum post is a great idea to request community feedback. Will publishing to a branch make this extension available for testing via stable snapcraft?

[mr-cal]

We have done extensive research on the existing practices. The plan was to get this added as an experimental extension to allow widespread testing (assuming this is the whole point of experimental extensions) and validate the proposed configuration schema for the snap options keys. A forum post is a great idea to request community feedback. Will publishing to a branch make this extension available for testing via stable snapcraft?

It would be available in a branch along the lines of edge/PR-4925. From a conversation between Gustavo and @cmatsuoka last week, I believe that feedback and agreement is needed prior to landing the PR. I think we have a misalignment/miscommunication - @cmatsuoka, can you chime in here?

update: we could also land this and #4926 into a feature/env-injector-extension branch.

[cmatsuoka]

Thanks! I think we need more discussion on this before landing to main, but even for a feature branch it would be interesting to refactor the test case to avoid splitting the extension test between the spread task scriptlet and verifications done inside C code, ideally both sides should reside in the task scriptlet (and maybe the C code can be entirely dropped).

Also compressing the rust binary can be pointless since the snap payload is already compressed (we should investigate other ways to reduce the binary size if a binary is to be used at all.)

[cmatsuoka]

Let's not forget that we still need this to be presented and discussed in the forum before landing it to main. In any case the injector code should reside in a separate repository instead of being part of the snapcraft codebase, and we must carefully consider if the extension is needed at all (the changes to snapcraft.yaml look too simple and can be easily added manually by the snap author).

[mr-cal]

From a code perspective, I think this is well written and tested. The documentation looks great too, although I didn't see anything about needing a configure hook.

Approving so we can land this into a feature branch this week to facilitate testing.

Update: I spoke with Claudio and he has some feedback before we move to a feature branch.

[locnnil]

@mr-cal Good point! I've added a note section about the need for a configure hook. Thank you!

[locnnil]

@mr-cal Just saw your update! Thanks for letting me know! I'll be waiting for @cmatsuoka feedback.

[cmatsuoka]

Thanks! The remaining restriction I have is that the injector code should reside in a separate repository, as a stand-alone project, instead of being part of the Snapcraft codebase. That way, it can be maintained separately without requiring Snapcraft maintainers to own the injector code. After establishing it as a separate project we can land the extension code on a feature branch for tests.

Before landing on main we'll probably need to revisit the bash vs rust implementations of the injector to see if the former can be optimized to be faster, or the latter can be optimized to be smaller (e.g. using no_std and adding some local helpers).

[locnnil]

@cmatsuoka The snappy-env (the exporter program) code is now separated from the extension and resides here: https://github.com/canonical/snappy-env

[farshidtz]

I've done some smoke testing and it looks good. There is a change to multipass command flags for spread testing which I think shouldn't be here.

Not a major issue, but env-exporter has been renamed to snappy-env (for good reasons since it also loads env files), but the surrounding refactoring is incomplete. It is still called env-exported in a few places. The extension adds a part named env-injector/env-injector which could also change to env-injector/snappy-env.

[cmatsuoka]

Thank you. Now we can work on the exporter independently, and investigate if it could be no-std to reduce binary size, or experiment and compare to a fast shell script implementation.