singularity-cli icon indicating copy to clipboard operation
singularity-cli copied to clipboard

ENV directive ignored when converting Dockerfile to Singularity def

Open d3v-null opened this issue 1 year ago • 2 comments

Expected Behavior

A Dockerfile converted to a Singularity def should respect the ENV directives.

Actual Behavior

Steps to Reproduce

I have a Dockerfile that uses an ENV directive.

FROM ubuntu:20.04 as base

ENV DEBIAN_FRONTEND="noninteractive"
RUN apt-get update && \
    apt-get install -y tzdata
> docker build -f Dockerfile .

#5 14.16 Setting up tzdata (2024a-0ubuntu0.20.04.1) ...
#5 14.19 
#5 14.19 Current default time zone: 'Etc/UTC'
#5 14.19 Local time is now:      Wed Aug 21 01:48:43 UTC 2024.
#5 14.19 Universal Time is now:  Wed Aug 21 01:48:43 UTC 2024.

When I convert that to a singularity def, it looks like this.

> spython recipe Dockerfile | tee Singularity.def

Bootstrap: docker
From: ubuntu:20.04 
Stage: base

%post

DEBIAN_FRONTEND="noninteractive"
apt-get update && apt-get install -y tzdata
%environment
export DEBIAN_FRONTEND="noninteractive"
%runscript
exec /bin/bash "$@"
%startscript
exec /bin/bash "$@"

Separate issue but I find that I need to manually update Bootstrap to get it working.

sed -i'' 's!Bootstrap: docker!Bootstrap: library!' Singularity.def

Anyway when I build that def, DEBIAN_FRONTEND is not seen by apt-get because it's not exported.

Setting up tzdata (2024a-0ubuntu0.20.04.1) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Configuring tzdata
------------------

Please select the geographic area in which you live. Subsequent configuration
questions will narrow this down by presenting a list of cities, representing
the time zones in which they are located.

  1. Africa      4. Australia  7. Atlantic  10. Pacific  13. Etc
  2. America     5. Arctic     8. Europe    11. SystemV
  3. Antarctica  6. Asia       9. Indian    12. US
Geographic area: 

export DEBIAN_FRONTEND="noninteractive" fixes this.

Why doesn't the conversion tool export ENV directives in the singularity def?

Context

[provide more detailed introduction to the issue itself . This is for make a reproducible issue.]

  • Operating System: macOS Sonoma 14.5 (M2)
  • singularity version: N/A
  • spython version: 0.3.13
  • python version: 3.12.4

Failure Logs

N/A

Possible Fix

export variables defined as ENV

d3v-null avatar Aug 21 '24 07:08 d3v-null

An ENV is converted to the environment section, which we see:

%environment
export DEBIAN_FRONTEND="noninteractive"

If you want the envar to appear in the run command, you could put it there. Do you have a suggestion for how to disambiguate between build and runtime envars? The above is the default because there is no distinction.

vsoch avatar Aug 21 '24 08:08 vsoch

I am experiencing the same issue. I think the source of the problem is indeed that there is no distinction between build and runtime envars in Dockerfile. For that matter, there is no specification for separate envars for commands and entrypoints. However, this tool is supposed to translate Dockerfile to apptainer definition; I think it'd be best that it preserves the semantics and behavior of the Dockerfile and the docker build process.

As the semantics of ENV is such that it IS position-sensitive and subsequent RUN commands are dependent on its visibility, I would argue that

export DEBIAN_FRONTEND="noninteractive"

at the point of "ENV" definition is the right solution. Adding the envar to the run command is a "manual" workaround, and would not be practical in all cases, e.g. automating the conversion of many Dockerfiles from different sources to apptainer definition files prior to building images (we prefer to build apptainer images directly as it avoids the storage overhead of intermediate docker images).

My 2 cents.

tcpan avatar Feb 12 '25 00:02 tcpan

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Apr 26 '25 04:04 stale[bot]