I've added the following to my requirements.txt file to be used in a Heroku app:
git+https://username:my_real_password#bitbucket.org/user/repo.git
However, I don't want the password in my repo, so I want to create an enviromental variable in Heroku called PASSWORD and set it equal to 'my_real_password'.
I then change the line in the requirements file to:
git+https://username:$PASSWORD#bitbucket.org/user/repo.git
but pip interpret my password as $PASSWORD.
So my question is, how can I force pip to lookup an environmental variable? Is there some escape character I can use?
Related
How can I edit the conda prompt's behavior without touching my normal prompt? I want to retain conda's prepend-to-PS1 behavior, but change the string that gets prepended.
The question how to modify conda 'source activate' ps1 behavior is very similar. However, the solution there is to either inject the conda prefix into the middle of PS1 and/or edit PROMPT_COMMAND. This breaks the encapsulation I want, and is very hacky when the prepend-to-PS1 behavior is still desirable.
My normal prompt string looks like this:
previous output
previous output
user#short-domain fullpath
$
This is the behavior I want when no conda environment is active. With a conda environment active, this becomes:
previous output
previous output
(<env-name-here>)
user#short-domain fullpath
$
I don't like how this eliminates the blank line between the previous command's output and the new prompt. Unlike the question I mentioned above, I specifically want (<env-name-here>) on its own line:
previous output
previous output
(<env-name-here>)
user#short-domain fullpath
$
Note how this means the conda prompt modification needs to include its own newline character. I could hack the other question's answers into working, but again, I don't want to touch any variables related to my normal prompt.
There is a proper and very simple way to do this using conda's native
configuration options.
Edit the .condarc file to contain the line:
env_prompt: \n({default_env})
or run the command:
$ conda config --system --set env_prompt "\n({default_env})"
Either of these will achieve the desired effect for new terminals.
Note that the --system option may not be desirable for many use cases.
See the explanation below for more details.
From the conda documentation
This feature can be elusive if you don't know where to look. The most
natural way to find it is to start with the configuration section
of the conda user guide.
The "using the .condarc conda configuration file" overview tells
us:
The conda configuration file, .condarc, is an optional runtime
configuration file that allows advanced users to configure various
aspects of conda, such as which channels it searches for packages,
proxy settings, and environment directories. For all of the conda
configuration options, see the configuration page.
The configuration page describes the setting we want, along with
its default value:
# env_prompt (str)
# Template for prompt modification based on the active environment.
# Currently supported template variables are '{prefix}', '{name}', and
# '{default_env}'. '{prefix}' is the absolute path to the active
# environment. '{name}' is the basename of the active environment
# prefix. '{default_env}' holds the value of '{name}' if the active
# environment is a conda named environment ('-n' flag), or otherwise
# holds the value of '{prefix}'. Templating uses python's str.format()
# method.
#
env_prompt: '({default_env}) '
The conda config command
The conda config command is quite useful on its own. Doing
$ conda config --describe
shows the same information as the configuration page.
Since my .condarc file is in a non-default location, I use the --system option
for conda config to prevent conda from creating a new .condarc file in my
home directory. From conda config --help:
Config File Location Selection:
Without one of these flags, the user config file at '$HOME/.condarc' is used.
--system Write to the system .condarc file at
'<my-anaconda-install-path>/.condarc'.
--env Write to the active conda environment .condarc file
(<current-env-path>). If no
environment is active, write to the user config file
($HOME/.condarc).
--file FILE Write to the given file.
I have a conda environment that I created with a path (conda create -p /full/path/to/env). When I activate the environment it displays the full path to the environment in parentheses at the beginning of the command prompt line. like
(full/path/to/env) [username#server]
I want to change it so it just shows env instead of full/path/to/env. How do I do that?
I tried adding the directory leading up to my conda environment (i.e. full/path/to) to my env_dirs configuration using conda config but that didn't work.
I'm using the oh-my-zsh dotenv plugin, which loads .env file, if it exists, whenever I cd into a project directory.
I know it works because I can see my custom environment vars set when I run the set cmd.
I can can also echo my custom environment variable from command line:
$ echo $FOO
'foo'
However, I cannot access this environment variable via the env command or Ruby:
$ irb
2.4.1 :001 > ENV['FOO']
nil
How can I make sure environment variables loaded from my .env are accessible from Ruby?
Contrary to what is stated in the documentation of dotenv, you actually need to use the export keyword within the .env file in order to make the parameters available to the environment, e.g.
export FOO=foo
The only exception would be, if the parameter was already an environment variable. For example if it had been exported in ~/.zshrc or if it was already part of the environment zsh got when it started (e.g. PATH or HOME).
All dotenv does is automatically sourcing any .env file when changing into a directory. There is no additional "magic". That means .env needs to be a valid zsh script and its content is run in the context of the current shell session (essentially as if you typed it manually).
It also means that the usual rules apply. That is, just settings parameters makes them available to the current shell context only. In order to make them available as environment variables they need to be exported (either before, during or after being set). So unless a parameter has already been exported before, export is not really "optional" in .env.
I'm using docker-maven-plugin. And it said -
"By default the plugin will try to connect to docker on localhost:2375. Set the DOCKER_HOST environment variable to connect elsewhere.
DOCKER_HOST=tcp://<host>:2375
Other docker-standard environment variables are honored too such as TLS and certificates.".
After I protect the Docker daemon socket reference to https://docs.docker.com/engine/security/https/. I think I need to set some variables like DOCKER_TLS_VERIFY="1" and also variable which is used to locate ca.pem file. So where could I find these docker-standerd environment variables?
You would find (and set) them on the same user that is running the docker-client.
EG:
nick#primestorage01:~$ set | grep DOCKER
DOCKER_HOST=terrorbyte:2376
DOCKER_TLS_VERIFY=true
You can do that many ways for an interactive login. One way is via a .bashrc file. (assuming you are using bash)
In .bashrc, you can add these lines:
#docker
export DOCKER_HOST=terrorbyte:2376
export DOCKER_TLS_VERIFY=true
If this is some sort of automation, depending on your methodology .bashrc won't be called (Specifically, if it's a non interactive shell such as via ssh host COMMAND. In this case, you'll need to set the environment variables another way.
PS, make sure you also put the certificates in the expected directory to make your life easier. The expected directory is ~/.docker
Does anyone know how to automatically set environment variables when activating an env in conda?
I have tried editing */bin/activate, but that adds the new environment variables for every new env that is created. I want to set env variables that are specific to each env.
Use the files $CONDA_PREFIX/etc/conda/activate.d and $CONDA_PREFIX/etc/conda/deactivate.d, where $CONDA_PREFIX is the path to the environment.
See the section on managing environments in the official documentation for reference.
Environment Variables as Configuration Settings
Conda v4.8 introduced a new command-line interface in the conda-env tool for managing environment variables on a per-environment basis. The command is conda env config vars and here is the help description as of v4.8.3 for the command overall:
$ 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
Perhaps a bit verbose, but it avoids having to manually manage files in etc/conda/(de|)activate.d.
YAML Specification
Added in Conda v4.9, there is now support for automatic defining of environment-specific variables as part of an environment YAML definition. For example,
name: foo
channels:
- defaults
dependencies:
- python
variables:
MY_VAR: something
OTHER_VAR: ohhhhya
which would set up the environment variables MY_VAR and OTHER_VAR to be set and unset on environment activation and deactivation, respectively.
The accepted answer (conda/activate.d and conda/deactivate.d) works well enough, but it is inconvenient if you want the environment variables to be version controlled without putting the entire environment into version control too. Generally you'd want to store only the environment.yml file in version control.
(I understand that this does not apply to all projects - sometimes the entire reason for using environment variables is to prevent that particular configuration getting stored in version control.)
My preference (on Windows, but the same principle would apply on Linux) is to create a (version-controlled) activate.cmd file in the root of the project directory that sets the environemnt variable(s) and then calls conda's own activate.bat script.
Example (a per-project pylint configuration):
set PYLINTRC=%cd%\pylintrc
#activate.bat %cd%\env
Note that on Windows at least you have to set the environment variables before calling activate.bat because the call to activate.bat never returns to the calling batch file. You also have to name your own script something other than activate.bat to avoid recursion, which is why I chose the cmd extension (which is treated by Windows as a batch file in this context).
So for virtualenv on Ubuntu I did the below where my virtual environement names is my_env and my environmental variables I want to persist were VAR_A and VAR_B:
virtualenv my_env
vim my_env/bin/activate
This opens the file and you can append your env variables to the end of the file like the below:
# This is me env variables to persist
export VAR_A=/home/developer/my_workspace/var_a
export VAR_B=/home/developer/my_workspace/var_b
Then exit the file.
Activate your virtualenv with
source my_env/bin/activate
Then your env variables should be good. Can verify like the below:
printenv | grep VAR_
VAR_B=/home/developer/my_workspace/var_b
VAR_A=/home/developer/my_workspace/var_a