Open brianbruggeman opened 4 years ago
I'm a bit confused as to what you're trying to accomplish.
If your .test-venv
is the virtualenv for a project you could activate it without using poetry (. ~/.test-venv/bin/activate
). Then use poetry's package management commands as usual, (ie not poetry run
or poetry shell
).
If your .test-venv
is where your "system-level" poetry is installed and you're trying to start a new project you could do ~/.test-venv/bin/poetry new new_project_name
. This would create a new virtualenv for this project, however, you would still have to activate using the above method.
Or are you trying to create a new blank virtual environment without a pyproject.toml
? Something like vex foo
or python -m venv foo
?
One possible solution for the first two is to change this line in poetry/console/commands/shell.py
so that it checks if poetry is running from the project's virtualenv or it's "system-level" virtualenv. Maybe by setting the "system-level" venv path as a config option?
I believe the last option would require poetry to become a packaging, dependency, and virtualenv manager by taking on some of the features of vex
. Possibly through a new command, something like poetry venv foo
would be equivalent to python -m venv foo; . foo/bin/activate
or vex foo
.
If the core team is interested in either of these solutions I'd be happy to try to implement them.
My motivation:
Our standard practice is to create a virtual environment independent of whether or not a package exists. From a higher level, virtual environments should generally be ephemeral. If I need to test that a package installs correctly, I want the ability to spin up a new environment and check out the installation. I think that this should be pretty common in a CI environment. And it may be especially relevant when building docker images with multiple stages.
So in answer to your question: yes, I wanted a completely empty virtual environment. And yes, I don't really want to have to install poetry at the system level. Without taking care to specifically control the virtual settings, poetry already creates a virtual environment to install when run from a "system level". So I think poetry already manages virtual environments, to a degree. But I think right now poetry is opinionated in that it assumes that poetry is installed to the system. I'm proposing that we make poetry a little more ergonomic for environments that don't want to support poetry as a system level dependency.
$ poetry shell -vvv
Using virtualenv: /home/user/.cache/pypoetry/virtualenvs/audition-r4d38FOu-py3.8
Spawning shell within /home/user/.cache/pypoetry/virtualenvs/audition-r4d38FOu-py3.8
audition $ . /home/user/.cache/pypoetry/virtualenvs/audition-r4d38FOu-py3.8/bin/activate
bash: /home/user/.cache/pypoetry/virtualenvs/audition-r4d38FOu-py3.8/bin/activate: line 35: syntax error near unexpected token `}'
bash: /home/user/.cache/pypoetry/virtualenvs/audition-r4d38FOu-py3.8/bin/activate: line 35: `}'
strange
$ exit
$ python -m venv .venv
$ echo $SHELL
/bin/bash
$ source .venv/bin/activate
bash: .venv/bin/activate: line 35: syntax error near unexpected token `}'
bash: .venv/bin/activate: line 35: `}'
$ bash --version
GNU bash, version 5.0.18(1)-release (x86_64-alpine-linux-musl)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
oh, it's still happens python-poetry/poetry#2478
As you note, this is a duplicate of python-poetry/poetry#2478. And as https://github.com/python-poetry/poetry-plugin-shell/issues/21 seems to show that you can reproduce it without poetry being involved: looks like nothing to do with poetry.
[x] I am on the latest Poetry version.
[x] I have searched the issues of this repo and believe that this is not a duplicate.
[X] If an exception occurs when executing a command, I executed it again in debug mode (
-vvv
option) (Not applicable).OS version and name: macos 10.15.6
Poetry version: 1.0.10
Link of a Gist with the contents of your pyproject.toml file: N/A
Issue
The basic issue is that poetry shell cannot be invoked within a virtual environment. Based on how this runs, I think the expectation is that we install poetry into the system.
My expectation is that I can invoke a
poetry shell
and drop into a standard virtual environment (i.e. a subshell that runs similar to vex).Reproduceable steps:
The error will be something like:
However, the virtual environment is not active.