Monailabel is ignoring arguments (issue with PYTHONPATH?)

[dorkylever]

Describe the bug Hi All,

I'm trying to set up an easy install of monailabel on a PBS-based computing cluster (AWS is unavailable on our computing environment).
The computing enviroment mainly loads packages by the creation and use of Tool Command Language (TCL) modules which typically contains a pip install e.g. pip3 install -I --prefix="${APP_PATH}" monailabel==0.6.0 --no-warn-script-location

and then the required PATHs are adjusted accordingly:

mkdir -p ${APP_MODULE_PATH} cat<<EOF > ${APP_MODULE_PATH}/${APP_VERSION} #%Module1.0 source /opt/Modules/extensions/extensions.tcl soft-prereq python3/3.10.0 prepend-path PYTHONPATH /apps/python3.10.0/ prepend-path PYTHONPATH ${APP_PATH}/lib/python3.10/site-packages prepend-path PATH ${APP_PATH}/bin EOF

However, when I load the module and run the monailabel command line, the command is reached but there is no following output, I supect due to something missing PYTHONPATHS. Example runs are below:

Server logs bash file used for qsubbing:

`[kd0793@gadi-login-05 0.6.0]$ cat bash_file.sh #!/bin/bash #PBS -P nm24 #PBS -q gpuvolta #PBS -l walltime=48:00:00 #PBS -l mem=100GB #PBS -l jobfs=200GB #PBS -l ngpus=4 #PBS -l ncpus=48 #PBS -lstorage=gdata/if89

module unload LAMA python3 module load monailabel/0.6.0 python3 -c "import torch; print(torch.cuda.is_available())" python -c 'import monai; monai.config.print_debug_info()' monailabel --help

output (standard output)

True Using PYTHONPATH=/g/data/if89/apps/monailabel:/g/data/if89/apps/monailabel/0.6.0/lib/python3.10/site-packages:/apps/python3.10.0/

Expected behavior Should bring up the help arguments for monailabel

[dorkylever]

so this is my monailable config:

monailabel.print_config() MONAILabel version: 0.6.0 Numpy version: 1.24.3 Pytorch version: 2.0.1+cu117 MONAILabel rev id: 40fd783a704f4d6a0baa8d34086dd336efdf1e6f

[SachidanandAlle]

1. latest 0.7.0 is released...
2. Not able to understand the error.. can you share the screenshot of your console?
3. what command you finally ran and not executed according to you

[dorkylever]

1. Ok so I'll use the latest from now on, thanks for letting me know

2. So I think the issue is within bin/monailabel not passing something properly. I can use the main script by calling python but using the command line is not working:

3. Same commands as the screenshot above.

4. What should ${MONAILABEL_PYEXE} be and when is the path typically specified in the install?

[SachidanandAlle]

Its because the way you have installed monailabel under apps is little bit different. In such you can try.. monailabel --prefix /g/data/if89/apps --help

if this is also not working.. then possibly you explicitly add path into PYTHONPATH and run

[dorkylever]

so adding the prefix has no effect on the PYTHONPATH:

neither did adding $PATH into $PYTHONPATH:

[SachidanandAlle]

Try to use GitHub source instead of pip install..

[dorkylever]

So I downloaded the latest release (https://github.com/Project-MONAI/MONAILabel/archive/refs/tags/0.7.0.tar.gz)

then ran:

tar xvzf 0.7.0.tar.gz

cd MONALabel-0.7.0

python3 setup.py install --prefix=/g/data/if89/apps/monailabel/0.7.0/

but the command line still failed. I have to specify the above prefix as home directories on our system only has a limited space / other write protection issues.

What is this line in the monailabel executable meant to point to:

export PYTHONPATH=$DIR:$PYTHONPATH

I'm guessing it's meant to be point to the monailabel folder (so you can find the sample-apps etc. ) but I pointed it directly to that path and it still had the original error (same as above). It's either that or some kind of OS-dependent issue with bash sourcing

Ultimately, this isn't too major of an issue as I can just call the python script and its happy once you specify the correct prefix. It would just be nice for more at an end-user level.

[hubutui]

It would be easier if you could use a conda environment. Then all you need to do is run pip in your virtual env. Steps looks like this:

1. install miniconda into somewhere we have write permission, eg: /data/miniconda.
2. activate conda command by source /data/miniconda/etc/profile.d/conda.sh, you could add this command to your .bashrc for convenience.
3. create a virtual env for monailabel, conda create -n monailabel python=3.10 -y.
4. activate the env we just created: conda activate monailabel.
5. install all package you need in this env, eg: install pytorch by conda install pytorch torchvision torchaudio pytorch-cuda=11.7 -c pytorch -c nvidia. We could also use pip command, eg: install monailabel by pip install monailabel. Note we don't need --prefix for pip command here. I think that's the issue you encounter.
6. we could now write a PBS script for submission, something looks like:

# make conda command available
source /data/miniconda/etc/profile.d/conda.sh
# activate the env we will use
conda activate monailabel
# run your script that use monailabel here
python main.py
# or start monailabel app by
monailabel start_server --app pathology --studies dataset

[dorkylever]

Is there any detriment to just calling the python script?

Whilst we can do conda envs, they're typically disliked by people who maintain our HPC resources who will always recommend to build from source (this way, the same env is used by everyone and they don't have to go into specific conda envs). If there's no detriment in terms of performance, it would ultimately be in our interest to just call the python script instead of setting up a conda env.

[dorkylever]

That or I'll have a look to see what's going fully run in the executable and then suggest a pull request.

[hubutui]

If you use conda env, you could install all the python pkg with the specific release you need. It's a tough job for HPC administrators to maintain many module files that users could run module load xxx to use. The disadvantage is you need more storage in order to create the conda env.

BTW, the people who maintain your HPC provide many module files and compile much software from the source? You're so lucky. I used to help with the cluster maintainer, and they only provide the necessary build tools (anaconda, nvidia driver, cuda). Users have to install their pkg in a conda env and maintain that for themself.

[annkapopp]

I had the same problem and solved it by setting "python" as an alias of "python3". You can also install python-is-python3 for this.

[evaherbst]

I am also experiencing this problem using a conda venv (with anaconda).