This bug was spotted running tests/tests.sh on LUMI. When creating a conda container common.sh cannot be sourced as there is a bash error in line 12 of generate_wrappers.sh: line 12: conditional binary operator expected.
Reproduce
conda_base.yml >>
channels:
- conda-forge
dependencies:
- numpy
req.txt >>
pyyaml
mkdir -p TEST_DIR/CONDA_INSTALL_DIR
conda-containerize new TEST_DIR/conda_base.yml -r TEST_DIR/req.txt --prefix TEST_DIR/CONDA_INSTALL_DIR
Opening a simple python shell e.g TEST_DIR/CONDA_INSTALL_DIR/bin/python :
hpc-container-wrapper/tests/TEST_DIR/CONDA_INSTALL_DIR/bin/../common.sh: line 12: conditional binary operator expected
hpc-container-wrapper/tests/TEST_DIR/CONDA_INSTALL_DIR/bin/../common.sh: line 12: syntax error near `singularity/mnt/session'
hpc-container-wrapper/tests/TEST_DIR/CONDA_INSTALL_DIR/bin/../common.sh: line 12: `if [[ grep singularity/mnt/session /proc/self/mountinfo ]];then'
It seems that sourcing common.sh is the problem
-bash: TEST_DIR/CONDA_INSTALL_DIR/common.sh: line 12: conditional binary operator expected
-bash: TEST_DIR/CONDA_INSTALL_DIR/common.sh: line 12: syntax error near `singularity/mnt/session'
-bash: TEST_DIR/CONDA_INSTALL_DIR/common.sh: line 12: `if [[ grep singularity/mnt/session /proc/self/mountinfo ]];then'
Suggested solution
Quick tests show that removing the [[...]] solves the problem. If you can think of a more elegant solution please contrib :).
Not tested on Puhti
Not tested on Mahti
Not tested with pip-containerize or wrapped installation, however off the top of my head I can't see any problem.
The above shouldn't be a problem unless the bash versions are vastly different.
This bug was spotted running
tests/tests.sh
on LUMI. When creating a conda containercommon.sh
cannot be sourced as there is a bash error in line 12 ofgenerate_wrappers.sh
:line 12: conditional binary operator expected
.Reproduce
conda_base.yml
>>req.txt
>>mkdir -p TEST_DIR/CONDA_INSTALL_DIR
Opening a simple python shell e.g
TEST_DIR/CONDA_INSTALL_DIR/bin/python
:It seems that sourcing
common.sh
is the problemSuggested solution
Quick tests show that removing the
[[...]]
solves the problem. If you can think of a more elegant solution please contrib :).The above shouldn't be a problem unless the bash versions are vastly different.