I have a tox.ini file like this:
[tox]
envlist =
{py27,py34}
[testenv]
setenv =
PYTHONDONTWRITEBYTECODE=1
deps =
-r{toxinidir}/requirements-test.txt
commands =
nosetests -v --stop --with-coverage --cover-package=project
So, I need to pass to my tox env an environment variable from my SO. This variable is private and changes according to the environment.
How I do it?
I found the solution! Tox 2.0 has a settings called passenv
A list of wildcard environment variable names which shall be copied from the tox invocation environment to the test environment. If a specified environment variable doesn’t exist in the tox invocation environment it is ignored. You can use * and ? to match multiple environment variables with one name.
Note that the PATH and PIP_INDEX_URL variables are unconditionally passed down and on Windows SYSTEMROOT, PATHEXT, TEMP and TMP will be passed down as well whereas on unix TMPDIR will be passed down. You can override these variables with the setenv option.
Related
For my python project, I am using Pipenv. On my local computer I have a bunch of AWS environment variables, that I don't want my virtual environment to use.
Each time my pipenv shell starts, I unset the variables - But for some reason, after each computer restart, upon activating the pipenv shell, I can see that the environment variables from my "parent" are being injected into the virtual environment.
Is there any way to disable this behavior, so that no environment variables are spilled over to my pipenv?
Is there any way to disable this behavior, so that no environment variables are spilled over to my pipenv?
This behavior can't simply be disabled because it is fundamental to how Unix processes work: a child process inherits the environment from the parent process. There are a few ways we can approach your question; the easiest is probably taking advantage of pipenv's support for loading .env files. If a .env file exists in the root of your pipenv project, then pipenv will load it whenever it runs.
So for example if in our parent environment we have:
SOMEVAR=somevalue
ANOTHERVAR=anothervalue
export SOMEVAR ANOTHERVAR
Normally, if we start a pipenv shell we will see those values in the new environment:
$ pipenv shell
$ env | grep -E 'SOMEVAR|ANOTHERVAR'
ANOTHERVAR=anothervalue
SOMEVAR=somevalue
But if we override those with empty values in a .env file:
$ cat > .env <<EOF
> SOMEVAR=
> ANOTHERVAR=
> EOF
Then that will take precedence when we start pipenv shell:
$ pipenv shell
$ env | grep -E 'SOMEVAR|ANOTHERVAR'
ANOTHERVAR=
SOMEVAR=
I currently have this script to show my GitHub branch and virtual env:
setopt PROMPT_SUBST
autoload -Uz vcs_info
precmd() { vcs_info }
zstyle ':vcs_info:git:*' formats '(%b)'
MYPS1=''
MYPS1+='%F{green}'
MYPS1+='${${(%):-%n}:0:1}'
MYPS1+='#'
MYPS1+='${${(%):-%m}:(-4)}' # Get last 4 chars of var machine name
MYPS1+=':'
MYPS1+='%F{yellow}'
MYPS1+='%1~' # Show only the name of the working directory or ~ if it is the home directory
MYPS1+='%F{magenta}'
MYPS1+='${vcs_info_msg_0_}' # Show git branch if any
MYPS1+='%f'
MYPS1+='%# '
PS1=$MYPS1
Sometimes I need to update my .zshrc so I run:
source ~/.zshrc
The problem is, whenever I reload my shell, I cannot see my Python virtual environment anymore even though it's still active.
# After activating virtual env
(my-ve-3.7.13) u#m1:repo-name(github-branch)%
# After reloading my zsh
u#m1:repo-name(github-branch)%
I use pyenv and virtualenvs.
How can I keep the virtual env name in my prompt?
Following #chepner's comment, I figured it out:
Use env to see the list of all env vars. pyenv uses PYENV_VERSION.
Add it to the prompt, use () to have the same look as pyenv does.
...
MYPS1=''
MYPS1+='($PYENV_VERSION) '
MYPS1+='%F{green}'
...
I created a python package with poetry.
I can control poetry's behaviour either with a config file and the config commands
poetry config virtualenvs.in-project true
or with environment variable VIERTUALENVS_IN_PROJECT=false.
If I specify a configuration in both places, which one will be chosen?
Setting export POETRY_VIRTUALENVS_IN_PROJECT=false in the .envrc with direnv has precedence over poetry.toml.
Right now I'm using virtualenv and just switching over to Pipenv. Today in virtualenv I load in different environment variables and settings depending on whether I'm in development, production, or testingby setting DJANGO_SETTINGS_MODULE to myproject.settings.development, myproject.settings.production, and myproject.settings.testing.
I'm aware that I can set an .env file, but how can I have multiple versions of that .env file?
I'm far from a Python guru, but one solution I can think of would be to create Pipenv scripts that run shell scripts to change the PIPENV_DOTENV_LOCATION and run your startup commands.
Example Pipfile scripts:
[scripts]
development = "./scripts/development.sh"
development.sh Example:
#!/bin/sh
PIPENV_DOTENV_LOCATION=/path/to/.development_env pipenv run python test.py
Then run pipenv run development
You should create different .env files with different prefixes depending on the environment, such as production.env or testing.env. With pipenv, you can use the PIPENV_DONT_LOAD_ENV=1 environment variable to prevent pipenv shell from automatically exporting the .env file and combine this with export $(cat .env | xargs).
export $(cat production.env | xargs) && PIPENV_DONT_LOAD_ENV=1 pipenv shell would configure your environment variables for production and then start a shell in the virtual environment.
Here is my tox.ini:
[tox]
envlist = py27,py35
[testenv]
deps =
Flask
connexion
pytest
coverage
pytest-cov
requests
six
commands=pytest --junitxml xunit-reports/xunit-result-XXX.xml --cov {envsitepackagesdir} --cov-report=xml
[testenv:local]
#HOW DO I SPECIFY A NEW LIST OF PYENV LIKE 31,36 IN HERE????
commands=
pytest --cov {envsitepackagesdir}/XXX --cov-report html
When I run tox it runs in py27 and py35. I want tox -e local to run in a different set of multiple python environments. I can't figure out how to do this. How do I do this? Right now it does not even respect the intial envlist and only runs on Python 2.7.
So what you want is to have two different sets of environments and run them independently.
What you have to understand first is that envlist is a list of all environments that would be run if you invoke tox without the -e option.
The next thing you have to understand is that there is only one of these lists per tox.ini and that one is in the global [tox] section.
The other thing you have to understand is that the pyXX factors (factors are the parts of environment names that are separated by the - sign) have a special meaning for tox, because they instruct it to build an environment with a specific interpreter. They are also called "default environments" (see basic usage). If you don't ask for that factor when calling tox, then the basepython interpreter will be used to build the virtualenv (the interpreter you are invoking tox from).
so if you invoke tox -e local with a tox.ini like yours, it will execute what is defined in [tox:local] with the basepython, because you are not defining which python should be used to create the virtualenv, so it uses the same interpreter that you invoked tox with.
If you want to be able to invoke your local factor with other interpreters, independent from those other environments, the following could get you started (described in the v2 config docs):
[tox]
envlist = {py27,py35}-remote,{py31,py36}-local
[testenv]
deps =
Flask
connexion
pytest
coverage
pytest-cov
requests
six
[testenv:remote]
commands=pytest --junitxml xunit-reports/xunit-result-XXX.xml --cov {envsitepackagesdir} --cov-report=xml
[testenv:local]
commands= pytest --cov {envsitepackagesdir}/XXX --cov-report html
Check which envs this creates with:
$ tox -a
py27-remote
py35-remote
py31-local
py36-local
What envlist with the curly braces notation does, is create environment names by combining all factors with their permutations (this can have more dimensions also).
if you say tox without -e they will all run and all use the correct interpreter.
If you want to run the local envs only you will have to call it with:
$ tox -e py31-local,py36
Then only those two will run. The thing to take away here is that if you want to run a subset of all environments you have to ask for them with their full names. There is no "sub generation" or extra envlist magic. Just list the full names of the envorenments in a comma separated list and you are golden.
UPDATE
Today I learned that you can also use the generation syntax from the command line. So you could type:
$ tox -e 'py{31,36}'-local
Thank you #phd for pointing it out.
A possible solution to what you are attempting to do is to use tox -l to list all the environments, filter the ones you want, and then feed them back into tox -e.
For example, to run all environments that have "local" in the name (using bash):
tox -e $(tox -l | grep local | paste -sd "," -)
Step-by-step explanation:
tox -l lists all the environments, one on each line
grep local filters only the lines of the input which contain the word "local"
paste -sd "," - joins the lines of the input with commas
[tox]envlist is only a default — a list of environments to run when tox is invoked without option -e and without TOXENV environment variable. Once you use tox -e [tox]envlist is ignored.
You can run local environment with different python versions, but I don't know any way to run it multiple times. You have to list all environments explicitly:
tox -e py33-local,py34-local
You can shorten the command line using tox' conventions:
tox -e 'py3{3,4}'-local
Use generative envlist and factor-conditional settings.
[tox]
envlist = {py27,py31,py35,py36}-{default,local}
[testenv]
deps =
Flask
connexion
pytest
coverage
pytest-cov
requests
six
commands =
{default,local}: python --version
default: pytest --junitxml xunit-reports/xunit-result-XXX.xml --cov {envsitepackagesdir} --cov-report=xml
local: pytest --cov {envsitepackagesdir}/XXX --cov-report html
List all possible combinations of python version and factors using: tox -l
For your "local" case you'd invoke tox in the one of the following ways:
tox -e py31-local
tox -e py36-local
tox -e 'py3{1,6}'-local
Answer heavily influenced by #oliver-bestwalter's answer, but I couldn't get that to work properly for some reason.
OK I greatly appreciate and upvoted the other two answers here but what I ended up doing was different. It seemed onerous just to achieve a separate
python version and command.
What I ended up doing was just making a seperate tox.ini and calling it like tox -c tox-local.ini