-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nox session doesn't find pytest installed by poetry #101
Comments
Interesting. Which versions of Poetry and Nox do you use? |
I'm using these versions:
|
I get a somewhat related error using the
I suppose this is because both Nox and Poetry maintain their own virtual environments and |
Thank you for the detailed information! Can you also paste the output of So far, I have not been able to reproduce this. |
I have been able to reproduce this. Looks like Poetry silently falls back to creating its own virtual environment if it cannot use the virtual environment it's running in. Can you try removing both the Nox and Poetry environments for your project?
Specifically, I did the following to reproduce the issue: git clone https://github.com/cjolowicz/hypermodern-python.git
cd hypermodern-python/
git switch chapter02
nox -s tests -p 3.8
docker run --rm -ti -v $(pwd):/src -w /src python:3.8.3 bash
# in the container:
pip install nox==2020.5.24
curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python
source $HOME/.poetry/env
nox -s tests -p 3.8 -r The output shows that Poetry creates its own virtual environment instead of installing into the existing Nox environment:
In this case, the environment is unusable for Poetry because it was created outside of the container. The shebangs in the entrypoint scripts point to a Python interpreter located outside of the container.
|
I just checked and the tests run without problem on the CI server. Running locally on my machine however gives the above error. Removing the |
Thanks, some more questions then:
|
I'm on Ubuntu 16.04. The file
So it seems Running |
I just figured it out (though I don't completely understand why that behavior occurred). Apparently there was a conflict with an active Miniconda environment which was automatically activated through |
Glad you fixed it! Poetry detects that it is running in a Conda environment via the Well, at least that's my impression of what happened here. Not able to test this right now. |
Thanks for sharing that part of the source code, it seems relevant indeed (it was the "base" environment for me). However I still don't understand the difference between the two cases, since both times # Miniconda "base" active
env_prefix = "/home/dominik/miniconda3"
conda_env_name = "base"
in_venv = env_prefix is not None and conda_env_name != "base"
assert not in_venv
# Miniconda "base" deactivated
env_prefix = None
conda_env_name = None
in_venv = env_prefix is not None and conda_env_name != "base"
assert not in_venv So from there on it continues to that branch where I cannot spot a difference between the two cases anymore. I always assumed that the Nox venv would shadow the Conda venv, and the explicit check for I think I'll open an issue at Poetry since it seems to be related to their venv checks. |
Well, the From what I can tell, Poetry's behavior does seem to be at fault though: It should use |
You are right, I checked with a separate script which I invoked via # Miniconda "base" active
env_prefix = "/home/dominik/Projects/testpkg/.nox/test"
conda_env_name = "base"
# Miniconda "base" inactive
env_prefix = "/home/dominik/Projects/testpkg/.nox/test"
conda_env_name = None So in the first case this creates a false-positive for |
I created a corresponding issue. |
I'm having this same issue where it appears Nox is using the Poetry virtualenv, but I don't think I have the same root cause becuase I am not using miniconda (or any conda). I have been following along with Hypermodern Python using two different computers both setup in WSL from scratch exactly the same way. One works great and the other doesn't. Not sure why they are different. To answer the questions posed above: cache-dir = "/home/joe/.cache/pypoetry" |
Thanks for reporting your issue! Can you post the following?
|
Your question helped me find the problem. The nox version was 2019.5.30 which did not match what my other computer was using. I ended up actually reinstalling my Ubuntu instance (running as WSL on Windows 10) and have been worked through the same initialization steps again. I realized that the installation of nox didn't quite work as expected. Running "pip install --user --upgrade nox" did complete the install, but then the nox keyword would return
So I realized I had installed via sudo which installed the 2019.5.30 version. The underlying issue is that using the pip method to install nox did not add it to PATH, so I just needed to add
to my .bashrc file and reload the shell. Now it seems to work as expected. |
$ poetry config virtualenvs.in-project 1 Solves this issue. |
For people arriving here in 2022, I've found that I can get it to work if I execute nox within a poetry shell. |
I'm not able to run Nox without the warning My Nox file is: import nox
@nox.session(python=["3.8", "3.9", "3.10", "3.11"])
def tests(session: nox.Session) -> None:
session.run("poetry", "shell", external=True) # Same warning without this line
session.run("poetry", "install", external=True)
session.run("pytest") I'm using Poetry to manage the project which is set up with something like: poetry new testproj
cd testproj
poetry add --group dev nox pytest
poetry env use python3.11
poetry install
poetry shell My Python installations are managed through PyEnv and I have a Conda base environment activated at all time to avoid messing up the system Python. I tried to deactivate the Conda base environment but this yields the same warning. I know I can bypass the issue by installing the project using @nox.session(python=["3.8", "3.9", "3.10", "3.11"])
def tests(session: nox.Session) -> None:
session.install(".")
session.install("pytest")
session.run("pytest") This works great excepted that it duplicates the development requirements in two places: in the Nox file and in the Should I stick with this last solution or is there a better alternative for Poetry? |
as per @oneextrafact, the following works poetry run nox |
I'm following along the Hypermodern Python series and it seems in Chapter 2, Test automation with Nox there is a conflict between
nox
andpoetry
. Specifically when I use the examplenoxfile.py
:I get the following error:
(and the same for tests-3.7)
It seems that installing
pytest
viapoetry
as a dev dependency doesn't put it on the path. In the previous section of Chapter 2,pytest
was invoked throughpoetry
and this does work in thenox
session as well:Is this an issue with my setup or is it expected that
pytest
can't be run as a command when installed bypoetry
?The text was updated successfully, but these errors were encountered: