Skip to content
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

Detect Conda when looking for a virtual env #1432

Merged
merged 1 commit into from Oct 18, 2019

Conversation

maksbotan
Copy link
Contributor

Currently Poetry will detect that it is running in a usual virtual env
created with "python -m venv" and will not create an additional env.

This commit extends this logic to Conda, which uses different
environment variables to indicate running in a virtual env.

Conda's "base" env is treated specially to avoid polluting global
namespace.

Pull Request Check List

This is just a reminder about the most common mistakes. Please make sure that you tick all appropriate boxes. But please read our contribution guide at least once, it will save you unnecessary review cycles!

  • Added tests for changed code.
  • Updated documentation for changed code.

Note: If your Pull Request introduces a new feature or changes the current behavior, it should be based
on the develop branch. If it's a bug fix or only a documentation update, it should be based on the master branch.

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!

@kasteph kasteph added kind/feature Feature requests/implementations area/venv Related to virtualenv management labels Oct 5, 2019
@edisongustavo
Copy link

This is amazing and I'm looking forward to this PR!

@kasteph
Copy link
Member

kasteph commented Oct 12, 2019

@sdispater I just took a look at this PR and it looks good to me -- can we get this in 1.0 or 1.1?

@finswimmer finswimmer mentioned this pull request Oct 17, 2019
@sdispater
Copy link
Member

@stephsamson I think we can add it for the 1.0 release.

@maksbotan Can you rebase your branch onto the master branch?

@maksbotan
Copy link
Contributor Author

@sdispater just to clarify, master, not dev, correct?

@sdispater
Copy link
Member

@maksbotan Yes, master since it's the branch containing the code for the 1.0.0 release. 

Currently Poetry will detect that it is running in a usual virtual env
created with "python -m venv" and will not create an additional env.

This commit extends this logic to Conda, which uses different
environment variables to indicate running in a virtual env.

Conda's "base" env is treated specially to avoid polluting global
namespace.
@maksbotan
Copy link
Contributor Author

Well, I did it :)

@maksbotan maksbotan changed the base branch from develop to master October 18, 2019 14:34
@kasteph kasteph merged commit 01b01aa into python-poetry:master Oct 18, 2019
@maksbotan
Copy link
Contributor Author

Thanks a lot!
By the way, are there any plans for 1.0 release date?

michielboekhoff pushed a commit to michielboekhoff/poetry that referenced this pull request Oct 29, 2019
Currently Poetry will detect that it is running in a usual virtual env
created with "python -m venv" and will not create an additional env.

This commit extends this logic to Conda, which uses different
environment variables to indicate running in a virtual env.

Conda's "base" env is treated specially to avoid polluting global
namespace.
michielboekhoff pushed a commit to michielboekhoff/poetry that referenced this pull request Oct 29, 2019
Currently Poetry will detect that it is running in a usual virtual env
created with "python -m venv" and will not create an additional env.

This commit extends this logic to Conda, which uses different
environment variables to indicate running in a virtual env.

Conda's "base" env is treated specially to avoid polluting global
namespace.
conda_env_name = os.environ.get("CONDA_DEFAULT_ENV")
# It's probably not a good idea to pollute Conda's global "base" env, since
# most users have it activated all the time.
in_venv = env_prefix is not None and conda_env_name != "base"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maksbotan, @stephsamson it is useful to allow poetry install into "base" environment when we create Docker image because there no need to create multiple Conda environments inside the container.
Otherwise, the developer should be aware that Poetry will ignore "base" environment. It would be great to output a warning/notice message about this.

@RoelantStegmann
Copy link

Just wondering: will poetry solve with taking the conda packages into account? I couldn't really find that in the documentation and I had a bit of a confusing situation.

I recently did on a windows computer did

poetry install

But in my code I got complaints that numpy was not properly installed. So I installed it with conda, where we had only a version before available...

conda install numpy=1.19.1

And now I still get

(test) λ poetry show numpy
name         : numpy
version      : 1.19.2

(test) λ pip show numpy
Name: numpy
Version: 1.19.2

(test) λ poetry run python -c "import numpy; print(numpy.__version__)"
1.19.1

Only after poetry remove numpy it shows the correct version.

@nlhnt
Copy link

nlhnt commented Feb 17, 2021

I don't think this is working, speaking from Windows. Same thing as above happesn for pytest and anything else I'm trying to use in a poetry / conda project.

poetry show -v with dependencies commented out:

$ poetry show -v
$ Using virtualenv: C:\Users\username\.conda\envs\phy_sec

poetry show -v with dependencies defined, numpy = "^1.17"

Using virtualenv: C:\Users\username\.conda\envs\phy_sec

  Stack trace:

  6  ~\.conda\envs\phy_sec\lib\site-packages\clikit\console_application.py:131 in run
     status_code = command.handle(parsed_args, io)

  5  ~\.conda\envs\phy_sec\lib\site-packages\clikit\api\command\command.py:120 in handle
     status_code = self._do_handle(args, io)

  4  ~\.conda\envs\phy_sec\lib\site-packages\clikit\api\command\command.py:171 in _do_handle
     return getattr(handler, handler_method)(args, io, self)

  3  ~\.conda\envs\phy_sec\lib\site-packages\cleo\commands\command.py:92 in wrap_handle
     return self.handle()

  2  ~\.conda\envs\phy_sec\lib\site-packages\poetry\console\commands\show.py:82 in handle
     ops = solver.solve()

  1  ~\.conda\envs\phy_sec\lib\site-packages\poetry\puzzle\solver.py:65 in solve
     packages, depths = self._solve(use_latest=use_latest)

  SolverProblemError

  Because pyforming depends on numpy (^1.17) which doesn't match any versions, version solving failed.

  at ~\.conda\envs\phy_sec\lib\site-packages\poetry\puzzle\solver.py:241 in _solve
      237│             packages = result.packages
      238│         except OverrideNeeded as e:
      239│             return self.solve_in_compatibility_mode(e.overrides, use_latest=use_latest)
      240│         except SolveFailure as e:
    → 241│             raise SolverProblemError(e)
      242│
      243│         results = dict(
      244│             depth_first_search(
      245│                 PackageNode(self._package, packages), aggregate_package_nodes

conda list with grep to look for a dependency installed in conda env under test

conda list | select-string "numpy"
numpy                     1.17.4                   pypi_0    pypi
numpydoc                  0.9.1                      py_0    conda-forge

@phiresky
Copy link

Is there any way to disable this functionality? I only want to use conda for the python binary and system compiler etc, not for the environment. Now poetry just never creates an environment and instead installs its stuff in the conda env.

@austinmw
Copy link

austinmw commented Mar 24, 2023

Would also like to know how to disable this

@maksbotan
Copy link
Contributor Author

@austinmw as far as I remember this change, poetry would use Conda env if you specifically created one, distinct from Conda's base. My argument is that you made the env for a reason and it doesn't make sense to create another env, kinda nested in Conda's. Does this contradict your work flow?

By the way, I think this behavior might be broken in the latest releases. I believe I even reported the issue.

@austinmw
Copy link

@austinmw as far as I remember this change, poetry would use Conda env if you specifically created one, distinct from Conda's base. My argument is that you made the env for a reason and it doesn't make sense to create another env, kinda nested in Conda's. Does this contradict your work flow?

By the way, I think this behavior might be broken in the latest releases. I believe I even reported the issue.

Ah okay, I didn’t realize that this functionality doesn’t kick in for the base environment. That works for me then, thanks!

Copy link

github-actions bot commented Mar 3, 2024

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/venv Related to virtualenv management kind/feature Feature requests/implementations
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants