Closed TheChymera closed 7 months ago
asmacdo
commented
7 months ago My first guess is this looks like a nipype bug to me, theres some unusual magic happening in nipype with etelemetry
https://github.com/nipy/nipype/blob/master/nipype/__init__.py#L75-L89
Maybe try setting NIPYPE_NO_ET
asmacdo
commented
7 months ago Since nipype is doing some unusual load logic, maybe try import nipype.interfaces.io as nio like how samri does it.
yarikoptic
commented
7 months ago sorry -- too much text.. what is the problem question exactly?
meanwhile followed up on https://github.com/IBT-FMI/SAMRI/issues/119#issuecomment-1967917509
TheChymera
commented
7 months ago @asmacdo oh god. Thank you so much for bringing up that variable, I now remember everything. So yes, nothing is broken, I just forgot some finer points regarding how to use it:
f3444f102fb7 /opt/code # source /etc/profile
f3444f102fb7 /opt/code # python
Python 3.10.10 (main, Mar 26 2023, 17:29:04) [GCC 12.2.1 20230121] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from nipype.interfaces import fsl
>>>
KeyboardInterrupt
>>>
f3444f102fb7 /opt/code # cat /etc/env.d/98nipype
export NIPYPE_NO_ET=1We need to run source /etc/profile for NIPYPE_NO_ET to be loaded. Our produce_analysis.sh script has that command.
But now that I hit this snag (again), maybe we could do something about it?
On a normal Gentoo system, you only need that if you want to have the environment variables loaded in currently open sessions.
Each new session will auto-load the environment variables on startup via source /etc/profile.
Any idea why OCI images don't auto-do it when you start your shell?
asmacdo
commented
7 months ago According to ChatGPT
Invoking /bin/bash without -l (or --login) starts a non-login shell. Non-login shells do not automatically source /etc/profile or the user's .profile, .bash_profile, etc. They typically source ~/.bashrc.
So I guess you could add -l and see if that does it
TheChymera
commented
7 months ago @asmacdo thanks, can confirm https://github.com/con/opfvta-reexecution/commit/61d09b98defae91c5669706b49656a6fd3726340 fixes it 💛
As a short preface, the interactive container is not really needed for this study, it's just a shell entry point with possible utility for debugging. This issue came to my attention via a user relying on the opfvta-reexecution container as a way to gain containerized access to SAMRI (since there's no SAMRI container yet).
SAMRI uses nipype, and as part of running the preprocessing analysis nipype is imported. That works fine (at the beginning I quit as soon as the preporcessing started, but it would continue going). However, if I enter the container and try to import either nipype or analogous submodules of nipype which SAMRI imports, that fails:
Any ideas what could be going on @yarikoptic @asmacdo