Greeting, I wrote a little tool to manage applications on silverblue and I’m posting it here as other
may find it useful: podenv. Be advised it is still in early development and feedback are most welcome 
2 Likes
Nice tool, though I’ve got to admit, using camelCase in Python wounded my soul a bit. 
Looks awesome.
Can I use something other as base, e.g. python:3.6 ?
I like minimal base images that do only few things.
Thank you for having a look @refi64. Once the configuration schema is stable, I plan on rewriting it with a compiled language to improve starting time and installation (using something like rust or Lisp).
@dac73, I just added support for apt based image here, this is needed as the tool may update and install runtime packages. You can now define an environment as:
python:
image: python:3.6
command: ["python3"]
capabilities:
terminal: True
Then running podenv python will pull and create a local image named “python-3.6”.
Just tried it, this is awesome, thank you.
Looks like something that can replace my jerryriged bash scripts for Silverblue workflow
Is it ok to drop questions (mostly about usage while I’m testing) here or do you prefere issues on GH?
For example I tried to use rhel image, and then it fails because of no sudo.
2019-07-31 20:52:28,698 INFO podenv - Creating registry.redhat.io_rhel8_python-36
dnf is /usr/bin/dnf
Not root, Subscription Management repositories not updated
Error: This command has to be run under the root user.
error while running runtime: exit status 1
ERRO[0001] exit status 1
Failed to run buildah run --network host python-36-working-container dnf update -y
Another issue I got with python:3.6 image was access denied on the mounted folder.
@dac73 I can answer question here, or GH, or tristanC on freenode.
About subscription, you can either prepare the image manually, and use the local name in the image attribute, (prefix the tag name with ‘localhost/’ to ensure local image usage. Or using the imageCustomizations attribute should work (with latest master).
About access denied on the mounted folder, there could be extra checks for labels in the env.validateEnv procedure (e.g. for each mounts, check if labels is system_u:object_r:container_file_t:s0, otherwise either chcon the path, or disable seLinux (e.g. “–no-selinux”). Similarly for read/write permission, the tool may enforce “–uidmap” or “–root” capability.
I have only been using a single image (so that all packages are updated at once and to keep a single copy of common libs). To better support multiple images, the description schema could use a fork attribute so that a new image is created for an environment (and its child).