Provide metadata such as container name and version inside the container itself

[Jmennius]

At the moment there is no information about the container inside the container itself.
This means that your command line prompt can't display useful information such as container name to the user.

Describe the solution you'd like
When creating a container, the toolbox populates an empty /run/.toolboxenv file to indicate to itself and potentially other programs that this is a container/toolbox environment.
I propose to extend the usage of that file by putting shell environment style (like .env) VARIABLE=VALUE lines inside it.
We can start with TOOLBOX_CONTAINER_NAME, TOOLBOX_IMAGE_NAME and TOOLBOX_IMAGE_VERSION variables, toolbox would pupulate them at container creation time.
Later, we can add more variables or even allow users to specify their own.
This is also a backward compatible change (unless somebody was checking that the file is empty).

Describe alternatives you've considered
In #98 we've discussed patching container hostname with container name, but that approach is quite limited and has drawbacks like obscuring actual system hostname.

Additional context
This has been previously discussed in #98, there is a PR #383 implementing container name to hostname mapping and a PR #210 which makes it command-line option to specify the hostname.
I've originally proposed that in a comment.
There is also a feature request in containers/podman#6192. Personally, I prefer implementing this in the toolbox itself as it will better serve our needs (appropriate format and information).

FYI @HarryMichal, @debarshiray. It would be great to have this considerend for v1.0 milestone.

[debarshiray]

This should be addressed by containers/podman#6192

[Jmennius]

I've read the issue, and still think that toolbox-specific solution is more appropriate, just like flatpak has their own.
It doesn't look like a good idea to depend on podman to provide something that only the toolbox needs right now. We see how that plays out in implementation time, the format (they tend to use INI-based format but with toolbox we need a simpler format for the shell).

[debarshiray]

The problem of not being able to visually differentiate between containers is something that users of Docker and Podman also complain about. If we do it twice, once in Toolbox and then later in Podman, then the format of the metadata might change, and confuse people using it to customize their shells.

We had added /run/.toolboxenv as a convenient way to differentiate between generic Podman and Toolbox containers from inside a container. There are cases where /usr/bin/toolbox itself needs this distinction, but this isn't one of those scenarios.

Ultimately Toolbox containers are Podman containers with specific configuration, whereas Flatpak containers are something entirely different. We have already pushed forward various changes to Podman that were initially only needed for Toolbox (eg., podman create --dns none --no-hosts ..., podman exec --workdir ..., etc.), so this isn't new.

Doing this thing in Podman itself, has a higher chance of success that sticking it in Toolbox. It will receive a lot more input on what kind of metadata makes sense, the appropriate format, and more people actually willing to write the code. After all, if @HarryMichal or I had some spare time then one of us would have already written the code and submitted it to Podman. :)

[debarshiray]

Duplicate of containers/podman#6192