I was running some tests and ran the line below not realizing this was a global action.
conda env config vars set <my_var>=<value>
I continued to use this moving forward:
conda env config vars set <my_var>=<value> -n <name of my env>
But now I can't unset the variable I accidently set globally and it's becoming the default for the rest of my environments. In ./envs/conda-meta/state, I can view all of the environment configurations I've set for that environment. Is there an equivalent to this for your base (default) environment? I'm just looking for the file where it gets saved to so I can remove the config, but the Conda documentation doesn't tell me this.
The base environment also should have a conda-meta/state. But you can also use the unset subcommand:
Documentation
$ conda env config vars -h
usage: conda-env config vars [-h] {list,set,unset} ...
Interact with environment variables associated with Conda environments
Options:
positional arguments:
{list,set,unset}
list List environment variables for a conda environment
set Set environment variables for a conda environment
unset Unset environment variables for a conda environment
optional arguments:
-h, --help Show this help message and exit.
examples:
conda env config vars list -n my_env
conda env config vars set MY_VAR=something OTHER_THING=ohhhhya
conda env config vars unset MY_VAR
Usage
That is, doing something like
conda env config vars unset <my_var> -n base
would be far preferable than manually editing the conda-meta/state file.
Related
I'm making an installer using the below bash script. After activating the env and later on checking the active env using the conda info, it shows that No env is active. Please refer to the image
Even after installing dependencies, the packages are not installed in the env, instead it's getting installed in the base env.
The script-
#!/usr/bin/bash
set -euo pipefail
conda create --name count python=3.7 <<< 'y'
. $(conda info --base)/etc/profile.d/conda.sh
conda activate count
conda info
#install dependencies
pip install -r requirements_count.txt
Thanks in advance for going through the query!
First, iteratively using ad hoc installs is a bad pattern. Better practice is to predefine everything in the environment with a YAML. That can even include PyPI packages and requirements.txt files.
count.yaml
name: count
channels:
- conda-forge
dependencies:
## Conda deps
- python=3.9 ## change to what you want, but preferable to specify
## PyPI deps
- pip
- pip:
- -r requirements_count.txt
Second, conda activate is intended for interactive shells, not scripts. One can run a bash script interactively by including an -l flag in the shebang. But better practice is to use the conda run method, which is designed for programmatic execution of commands in a specified context.
Pulling this together, the script might be:
script.sh
#!/usr/bin/bash
set -euo pipefail
## create the environment
conda create -n count -f count.yaml
## execute a Python script in the environment
conda run -n count python my_code.py
If the code run in the environment needs to interact with a user or stream output, you may need additional flags (--no-capture-output, --live-stream). See conda run --help.
When I do conda info --envs, I get list of all envs and their locations like this:
# conda environments:
#
base * /Users/mbp/miniconda3
myenv /Users/mbp/miniconda3/envs/myenv
Is there a way to get the location of myenv environment from command line? May be something like conda info --envs myenv to get
/Users/mbp/miniconda3/envs/myenv
What's the use case?
I want to cache all the environment dependencies in GitHub actions. This has to happen before the environment is activated. If I know the location of the environment, I can cache all the files in it.
conda info --envs | grep -Po 'myenv\K.*' | sed 's: ::g'
This bash command will retrieve all envs from conda and find the line which starts from myenv and give it to the sed command which inturn removes the spaces
surprisingly it worked for me
$(conda info --base)/envs/myenv
Conda's internal function to handle prefix resolution (locate_prefix_by_name) is currently located in conda.base.context, so one could avoid listing all envs with a script like:
conda-locate.py
#!/usr/bin/env conda run -n base python
import sys
from conda.base.context import locate_prefix_by_name
print(locate_prexif_by_name(sys.argv[1]), end='')
Usage
# make executable
chmod +x conda-locate.py
./conda-locate.py jupyter
# /Users/user/miniforge/envs/jupyter
You may want to add a try..catch to handle the conda.exceptions.EnvironmentNameNotFound exception.
I was looking at the golang:1.10.2 Dockerfile (as of today), and couldn't understand why the PATH variable is being used in two different places. Here's the bottom of the file with the pertinent snippet:
RUN set -eux; \
# some code ...
export PATH="/usr/local/go/bin:$PATH"; \
go version
ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH
RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$GOPATH"
WORKDIR $GOPATH
What is the purpose of
export PATH="/usr/local/go/bin:$PATH";
and
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH
respectively?
My impression is that the ENV directive should be shortened to ENV $GOPATH:$PATH since /usr/local/go/bin is already in $PATH.
Each RUN (when not in the explicit-argv usage mode) starts a new shell, which must exit before that RUN command is complete. That shell can only change its own environment and that of its children; it can't change the environment of other programs started after it exits.
By contrast, ENV controls the environment that Docker passes to future processes when they're started.
Thus, you could move the ENV above the RUN and remove the export from the RUN (to have the PATH correctly set before the shell is started), but you can't make a RUN do the work of a ENV.
I have a script like so:
#!/usr/bin/env bash
eval $(docker-machine env default)
The goal is to automate the setting of variables like
export DOCKER_TLS_VERIFY
export DOCKER_HOST
export DOCKER_CERT_PATH
export DOCKER_MACHINE_NAME
But when I check afterwards, the variables are not set. This is not the case if I run each export command manually. What am I doing wrong?
export makes variables available only to the active shell session. If you want them to persist through sessions, you must add them to your bash profile:
docker-machine env default >> ~/.bash_profile
This way, the variables will be available in all future shell sessions. Make sure to restart the shell after executing the command.
If you want the environment set in your current shell you need to "source" the script rather than run it.
When you run a script, the variables will be set in the child bash processes environment and will not exist once that script/process dies.
$ ./machine.sh
DOCKER_HOST is tcp://192.168.99.100:2376
$ echo "[$DOCKER_HOST]"
[]
When you source a script, the variables will be set in your current environment
$ . machine.sh
DOCKER_HOST is tcp://192.168.99.100:2376
$ echo "[$DOCKER_HOST]"
[tcp://192.168.99.100:2376]
I am running Docker Machine on Mac.
docker-machine version 0.6.0, build e27fb87
In my shell I have done
export DOCKER_HOST=tcp://docker.local:2375
export DOCKER_TLS_VERIFY=0
Restarted the machine
When I do
docker-machine env
These do not seem to have been set. I am using the ZSH shell, could this be an issue?
docker-machine env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/ciaran/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
When you run docker-machine env it will show the variables that are needed in order to connect to the default machine. It has nothing to do with the variables in the current shell, and will not set any variables in your shell.
To see the current docker variables in your shell, you can run
$ env | grep DOCKER
If you want to set your shell ENV variables to the ones in docker-machine env, you will need to either copy and paste the output of docker-machine env, or eval the output like this.
$ eval $(docker-machine env <machine name>)
That will set the variables in your shell. This command is actually given to you when you run docker-machine env look at the end of the output.
To confirm it worked, check the shell again.
$ env | grep DOCKER