Hi,
For conducting a workshop, users need to access qiime2 installed on a server (for e.g., CentOS). With root privileges, some users accounts were created. Miniconda3 was installed (/opt/miniconda3), followed by qiime2-2019.4 as per instructions. Now, we are not sure how a user can access qiime2 from their accounts. What are the commands required to activate qiime2 by the user from their account? Please let me know the steps to follow so that users can access qiime2 and perform their analysis through their own accounts. Thanks!
Good morning!
The goal of conda is that each users installs all the software they need, so if you made three new user accounts, each one would need to install miniconda and qiime 2.
(The user accounts don’t need root access to install miniconda or qiime!)
I know this sounds like an extra step before people can use qiime, but this extra step is really important. This is the exact same process they would go through installing qiime on their own laptop, or on their own super-computer. So including the install step as the first part of the workshop is a really great way to start.
Let me know what you think.
Colin
1 Like
Hello @colinbrislawn,
I read one of the earlier posts on this topic and thought that it could be possible to do so. It is really a pain for all the users to install everything but I hope there is a way around. Pl. let me know what is your opinion on that post. Thanks!
Our group has a single Conda install in a shared directory in CentOS 7. For new users, we just copy contents of the ~/.bashrc file to theirs. They can use the environments, but things get a little tricky if they try to install new environments.
3 Likes
@jbisanz, do you have a base conda install on your system? Ive tried this a few times on my local server (not sure if it is CentOS 7), and Ive had to install miniconda each time. If theres a way to just directly access, it would make life so much easier.
I don’t believe so. Our server is connected to a SGE cluster, but I tend to reinstall local versions of pretty much everything. Based on the contents of the .bashrc, I think even if there was the local install would take priority.
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/turnbaugh/qb3share/shared_resources/Conda/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/turnbaugh/qb3share/shared_resources/Conda/etc/profile.d/conda.sh" ]; then
. "/turnbaugh/qb3share/shared_resources/Conda/etc/profile.d/conda.sh"
else
export PATH="/turnbaugh/qb3share/shared_resources/Conda/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<
1 Like
Cool. I’ve tried it with some students and we have both communal and local. You can shift if you comment out the export path and switch for your location. So, I switch semi regularly between the conda versions. But, I haven’t been able to get my students up and running without having to install conda on each account. So, I may need to try with this newer version.
@jbisanz , your approach worked on a Ubuntu machine but was not successful on a CentOS. @colinbrislawn, @jwdebelius, at the end single user installation was a better choice. 
1 Like
I think there is a conda solution that lets you install system wide, but I dont have server admin rights and haven’t been able to try. If you have a local installation, you can still access communal environments by switching out your path. But, the problem ends up being the magic architecture.
1 Like
.condarc is your friend here, in particular, the envs_dirs parameter. This let’s user-installs extend their environment path, which is a really great way to get access to other envs on the same machine.
FWIW, when hosting “official” QIIME 2 workshops, this is the provisioning script we use. We install QIIME 2 in a single shared environment for all users of the cluster. As well, our host institution (NAU) deploys QIIME 2 similarly, too.
2 Likes