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]

This could be simply unecessary as snap payloads are already compressed. Additionally, we can have other ways to produce leaner binaries that should be investigated (e.g. can we go the no_std way?)

Also we need the reasoning to implement this as a binary (as opposed to e.g. a shell script) explained somewhere. Having it as a script could make the need for an additional part unnecessary, and the whole extension would end up being very trivial, maybe to the point that any changes to snapcraft.yaml could be done manually by the user.

In the binary case, it's better to have the injector source in a separate repository instead of bundling it with snapcraft, and just point the part source to it.

[farshidtz]

This could be simply unecessary as snap payloads are already compressed.

Good point regarding the redundant compression. Need to do some comparison.

Additionally, we can have other ways to produce leaner binaries that should be investigated (e.g. can we go the no_std way?)

A few libraries were added to simplify HTTP query over Unix Socket, JSON parsing, env file parsing so we don't have to rewrite all that logic in the experimentation phase.

Also we need the reasoning to implement this as a binary (as opposed to e.g. a shell script) explained somewhere. Having it as a script could make the need for an additional part unnecessary, and the whole extension would end up being very trivial, maybe to the point that any changes to snapcraft.yaml could be done manually by the user.

This started as a Bash script but was rewritten in Rust due to performance concerns, mostly contributed to the number of queries to SnapD and JSON/string parsing. I do believe this was done prematurely.

In the binary case, it's better to have the injector source in a separate repository instead of bundling it with snapcraft, and just point the part source to it.

If the code gets moved to another repository, how can we maintain compatibility with the snap's base? Git branch per base? Which project / team will own that code?

[cmatsuoka]

This is a very simple snippet and snap authors are quite used to apply even more complex patterns to parts or applications in order to implement certain features, so this alone may not warrant the existence of an extension.

[farshidtz]

The selected snippet adds the env exporter program and the alias. The alias gets added only when the user hasn't set it (this is intended and based on snapcraft's internal handling of the dictionary).

The extension does more than that: It adds the source code for the exporter program, builds it and places it in the right location. The design also envisions additional functions, such as adding a configure hook when it isn't a present, or adding configuration validation.

If this was to be done manually, without the extension, the developers would have to:

1. Fetch the exporter source from trusted location, pick and appropriate version, and hope that it stays compatible with the snap. *
2. Add build logic to compile and place the executable in a suitable location *
3. For each application that needs the functionality:
   i. Add the exporter program to the command chain
   ii. Set the application alias

In comparison, when the extension is used:

1. Add the extension to each application that needs the functionality
2. Add alias if an app's name needs to be overridden

The manual way requires average snapping knowledge, which early adopters lack. I'd emphasize that the goal is to simplify the snapping of apps and all this complexity thrown at the developer defeats its purpose.

---

* We could make a snap or a debian package and let the developer stage it, but then we need to separately maintain that package.

[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).