Poetry: Document use of current conda env

[thorbjornwolf]

• [x] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

Thank you all for your excellent work! And congratulations on cutting out a stable release! 🍾

My misunderstanding

Prior to reading the 1.0.0 release notes, my (wrong) mental model was that poetry always creates a new virtualenv for the project under consideration.
Now I've learned that it reuses the current virtualenv, if one is active, and that it now does the same for a current conda environment.

Current state

It is wonderful to see conda envs become a first-class citizen of poetry (https://github.com/python-poetry/poetry/pull/1432).
However, conspicuously, the PR's checkbox for "Updated documentation for changed code" remains unchecked 😁

And so, looking around in https://python-poetry.org/docs/, I fail to find mention of this behaviour. I guess I would put documentation in (at least) section "Managing environments". I would, however, also like to see it mentioned elsewhere.

Finally, when I am in an active conda environment and run poetry install, I see no indication that the current environment is being used/updated/modified. There is instead a _lack_ of indication that a virtualenv is being created.

Desired state

This is a wishlist, for the consideration of the designers:

• I would like to see a command-line indication that the current (conda|virtual) env is being used when running commands relying on or modifying those. I think I prefer explicit state.
  
  
  
  • This is already the case for poetry shell, which helpfully says "Virtual environment already activated: "
  
  
• Documentation that "To achieve this, it will first check if it's currently running inside a virtual environment. If it is, it will use it directly without creating a new one." (from Managing environments) also counts for non-base conda environments

poetry debug info

Version: 1.0.0
Python:  3.5.4

Virtualenv
Python:         3.5.4
Implementation: CPython
Path:           C:\Users\me\AppData\Local\Continuum\anaconda3\envs\py3_5_4
Valid:          True

System
Platform: win32
OS:       nt
Python:   C:\Users\me\AppData\Local\Continuum\anaconda3\envs\py3_5_4

Thank you for your efforts!

[dazza-codes]

I want to add to this - I would go so far as to revert this behavior to the poetry 0.12 behavior by default, where it creates a new virtualenv for the poetry project (it will be a derivative of the existing conda virtualenv that is already active, it should not pollute that conda env). To provide flexibility for folks who want it either way, add a config option to control how this behaves.

I have used conda to manage python versions and do so by creating a conda virtualenv for each python version on my system. I then activate a conda env with a given python version and then use poetry for a given project that needs a specific python version; then poetry 0.12 creates and manages a new virtualenv. The conda-envs are treated like base environments for spawning new virtualenvs. The new poetry 1.x behavior now pollutes the base conda-envs that manage python versions - arghhh.

What's the alternative way to use poetry 1.x without polluting an existing conda base-env? At present, it seems like poetry install has no option to demand that a new virtualenv is managed by poetry. So, it requires manually creating a new conda env with conda create -n {name} python={project-python-version}, using conda to activate it, and then calling poetry install. The poetry 0.12 behavior was easier than this.

Side note - I no longer trust pyenv shims, take your pick of issues about it

• https://github.com/pyenv/pyenv/issues?utf8=%E2%9C%93&q=is%3Aissue+shim+

[dazza-codes]

For other conda folks landing here who do not want poetry 1.x to pollute a base conda environment, I use this short bash function to spawn a new python 3.6 conda-env for my projects (based on the project root directory name, which is often the git-clone directory).

conda-venv () {
    # create and activate a conda environment with
    # the name of the current directory (often this
    # is a project name).  Default to python=3.6
    local py_ver="${1:-3.6}"
    wd=$(basename $(pwd))
    conda deactivate
    conda create -y -n "$wd" python="${py_ver}"
    conda activate "$wd"
}

I use it like this:

git clone [email protected]:sdispater/poetry.git
cd poetry
conda-venv
poetry install

It's not awesome by any means, but it helps. Consider it an MIT license snippet, use at your own risk, and modify however you like. Note that it does wipe-out an existing cond-env to recreate it every time.