I recently stumbled upon an issue while trying out a few different setups. Actually don't fully recall now how I got
there, but what was happening was that after creating new projects with aiida-project create and activating them with
cda, my AIIDA_PATH environment variable was still pointing to the global $HOME/.aiida, and, accordingly, new
project-specific profiles were being added to the global config file $HOME/.aiida/config.json.
After some digging around, I realized that the issue was an incompatibility between my main shell (fish) and the fact
that I was occasionally launching and using bash. To be precise (and as I have recently, painfully learned),
environment variables of the parent shell cannot be set from a Python subprocess. Thus, in aiida-project, this is
instead handled via the cda command, which, apart from changing the directory, also sources the Python activation
file, activate.fish for fish and activate for bash when using venv. Importantly, aiida-project adds the
command to set AIIDA_PATH to this activation file, e.g. for fish in $HOME/.aiida_venvs/<project>/bin/activate.fish:
set -gx AIIDA_PATH $HOME/aiida_projects/<project>
eval (env _VERDI_COMPLETE=fish_source verdi)
with cda defined as follows:
# Defined in $HOME/.config/fish/conf.d/aiida_project.fish @ line 48
function cda
source "$aiida_venv_dir/$argv[1]/bin/activate.fish"
cd "$aiida_project_dir/$argv[1]"
end
Long story short, in my case, cda was pointing to activate not activate.fish, while the command to set
AIIDA_PATH was in activate.
Now, this might be somewhat of a niche case, however, I would propose that we move the location of setting AIIDA_PATH
and the eval statement for tab completion to a general, hidden activation file inside the directory of the project.
This change should also be necessary if we want to add conda support, as here the Python environment is not activated
by sourcing an activate file.
Lastly, as it stands right now, the shell is attached to the global configuration of aiida-project, so we could
instead attach it to each project, or, even better, implement a check on the currently running shell, so that seamless
use of aiida-project is guaranteed even when running with different terminal instances and shells (though, not
entirely sure how one would go about implementing that).
I recently stumbled upon an issue while trying out a few different setups. Actually don't fully recall now how I got there, but what was happening was that after creating new projects with
aiida-project create
and activating them withcda
, myAIIDA_PATH
environment variable was still pointing to the global$HOME/.aiida
, and, accordingly, new project-specific profiles were being added to the global config file$HOME/.aiida/config.json
.After some digging around, I realized that the issue was an incompatibility between my main shell (
fish
) and the fact that I was occasionally launching and usingbash
. To be precise (and as I have recently, painfully learned), environment variables of the parent shell cannot be set from a Python subprocess. Thus, inaiida-project
, this is instead handled via thecda
command, which, apart from changing the directory, also sources the Python activation file,activate.fish
forfish
andactivate
forbash
when usingvenv
. Importantly,aiida-project
adds the command to setAIIDA_PATH
to this activation file, e.g. for fish in$HOME/.aiida_venvs/<project>/bin/activate.fish
:with
cda
defined as follows:Long story short, in my case,
cda
was pointing toactivate
notactivate.fish
, while the command to setAIIDA_PATH
was inactivate
.Now, this might be somewhat of a niche case, however, I would propose that we move the location of setting
AIIDA_PATH
and theeval
statement for tab completion to a general, hidden activation file inside the directory of the project. This change should also be necessary if we want to addconda
support, as here the Python environment is not activated by sourcing anactivate
file.Lastly, as it stands right now, the shell is attached to the global configuration of
aiida-project
, so we could instead attach it to each project, or, even better, implement a check on the currently running shell, so that seamless use ofaiida-project
is guaranteed even when running with different terminal instances and shells (though, not entirely sure how one would go about implementing that).