Virtualenv Path no longer shown in debug:info with 0.12.2

[phobologic]

• I am on the latest Poetry version.
• I have searched the issues of this repo and believe that this is not a duplicate.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: MacOS 10.13.6
• Poetry version: 0.12.2
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/phobologic/07806ca3abbc52dbb73b3b4d0ace55e1

Issue

poetry 0.12.2 no longer displays the virtualenv path when poetry debug:info is run, and instead displays NA.

[Sharparam]

As a potential workaround, it seems possible to run debug:info with the run command to get the virtualenv path:

poetry run poetry debug:info

Not ideal obviously, but at least works to extract the path in my very limited testing.

Edit: This occurs in both the currently released 0.12.2 (poetry debug:info) and preview version 1.0.0b1 (poetry env info).

Edit 2: This might have something to do with naming:

When the project folder contains an underscore, poetry translates this to a dash, including in the generated virtualenv directory, even though it's supposed to be based on the containing directory name, and not the project name.

This works as expected:

poetry new simple
cd simple
poetry install
poetry env info -p

The above will output the path to the virtualenv.

This fails:

poetry new my_test
cd my_test
poetry install
poetry env info -p

The above will output an empty path with exit code 1. Running just poetry env info shows NA for the path.

However, poetry is obviously able to deduce where the virtualenv is, since it can run it just fine:

poetry run poetry env info -p

This outputs a path to a virtualenv my-test-<hash>-<py version>. Note how the underscores are replaced with dashes.

It also works if the directory is named with a dash instead of underscore.

So poetry seems to dislike underscores in some circumstances. Is this intended behaviour or a bug?

[sdispater]

The issue with the difference between the project name and the virtual environment name, leading to this issue, has been fixed in the latest beta release of the 1.0.0 version.

[github-actions]

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