Various issues when package name differs from directory name.

[KelSolaar]

• 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: maOS 10.14.6
• Poetry version: 1.0.0b1
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/KelSolaar/c2c853ca329899534494e2ddf8a1aa96

Issue

This relates to #705 but I'm not able to solve all my issues without massaging a few things. The PyPi package name of my project differs from the actual python package name:

• colour-science for the PyPi package.
• colour for the internal python package and same for the Github repository.

My pyproject.toml file was originally working fine when using colour for the name attribute:

[tool.poetry]
name = "colour"

When trying to build with poetry build, I noticed that it was generating a colour.0.3.13.tar.gz archive that would not work for PyPi, thus I changed the TOML file as follows:

[tool.poetry]
name = "colour-science"
packages = [
    { include="colour", from="." },
]

I was able to build, but now, after cloning the repo into a default colour directory, issuing poetry install creates a virtual environment with the colour-science prefix however the poetry env info -p command does not find the virtual environment because I'm assuming it is looking for an environment with the colour prefix instead.

So there is a consistency issue between how the name of the candidate virtual environment is generated with the poetry install command and the poetry env one.

It also seems like it would be useful to have an attribute to handle the PyPi distribution name explicitly.

Cheers,

Thomas

[KelSolaar]

So looking at the 1.0.0b1 code for getting the environment:
https://github.com/sdispater/poetry/blob/1caf20a291d3a494ab815a9b2746d2f152abb893/poetry/console/commands/env/info.py#L17 It looks like it is indeed relying only on the directory name to find the environment and not the name attribute value from the pyproject.toml file.

[pspeter]

I did some digging through the code and must say I'm quite confused by the EnvManager class. Its create_venv method is the only method that will - when supplied with name=poetry.package.name - at least sometimes correctly use the package name and create an environment based on it. BUT, if a venv with the name of the directory of the package also exists, it will always just pick that venv instead of using the correct package name, even if the name is supplied to the method. This seems like a (very much related) bug to me.

https://github.com/sdispater/poetry/blob/1814327603f2cfdd02c21db6a16773d7a0f08ffd/poetry/utils/env.py#L421-L424

The other methods of EnvManager don't even have a name argument and will always just use the directory name to build the environment name. If no environment based on the directory name exists, they will usually just use the system python.

All Commands that are derived from EnvCommand (which does not include the poetry env commands) do get a virtual environment through this EnvManager class, but only indirectly through the PRE_HANDLE dispatch event handlers. Basically, the application_config.ApplicationConfig sets up the ApplicationConfig.set_env() method as an event listener, which in turn calls the EnvManager.create_venv() method to supply each EnvCommand with an environment.

https://github.com/sdispater/poetry/blob/1814327603f2cfdd02c21db6a16773d7a0f08ffd/poetry/console/config/application_config.py#L91

This event listener is called right at the start of the base class Command.handle(), before the concrete classes code. The call to create_env() contains the name=poetry.package.name, which is why the commands mentioned in #1425 work correctly, while the poetry env commands do not.

Some commands like poetry init and poetry new use EnvManager.get(cwd) just to get the system Python to then check the python version. Meanwhile, the EnvManager.activate(), deactivate(), remove() and list() methods only get called by the poetry env commands. Short term, all of these probably should be changed to accept an (optional?) name attribute which will in turn be used instead of cwd to create the venv name. Long term, it might be a good idea to rethink the API of this whole class because it's confusing and non-intuitive.

I might take a stab at fixing this but I'm happy for all feedback and help as I'm quite new to the code base. Especially happy for help with writing the corresponding unit tests.

[sdispater]

The environment name issue has been fixed in #1477

[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.