Bugfix: Fix ignored `venv.in_project` config while creating venv

[xanterx]

Pull Request Check List

• [x] A news fragment is added in news/ describing what is new.
• [ ] Test cases added for changed code.

Describe what you have changed in this PR. Close #32

[frostming]

But this means the --name argument will be ignored and always override the existing venv.

Is this what users want?

[xanterx]

The way we are storing the name of virtual-env is storing by the value after the virtual-env path hash. (backend.py#L68).

Right now, if venv.in_project is true it is creating a by default name .venv (backend.py#L78). And the default key given to this is in-project (utils.py#L30).

If we consider overriding default in-project virtual-env name with the user supplied --name argument, and store the name as a part of in-project virtual-env folder name. This will override the default names used for in-project virtual-env folders. (pdm/utils.py#L294)

Therefore, in my opinion we should ignore the --name argument if venv.in-project config is true.

If you like user to still have an option and override this in-project virtual-env I can create a separate PR to update iter_venv func and also create one for pdm to recognize these names. or I can update the docs for above behaviour.

[frostming]

Therefore, in my opinion we should ignore the --name argument if venv.in-project config is true.

Maybe we can create venv in-project when --name isn't given.

[xanterx]

In my workflow when --name was not given pdm-venv created the virtual-env in the location given in venv.location. Which I expected it to be created. And it defaulted the name to the python version. I really liked that. From a user experience perspective, it made sense to me, that you will get in-project venv only if you enable venv.in_project flag.

[frostming]

In my workflow when --name was not given pdm-venv created the virtual-env in the location given in venv.location. Which I expected it to be created. And it defaulted the name to the python version. I really liked that. From a user experience perspective, it made sense to me, that you will get in-project venv only if you enable venv.in_project flag.

So can you make the change?

[xanterx]

Maybe we can create venv in-project when --name isn't given.

So, you want me to make this change. 👆

From a user experience perspective, it made sense to me, that you will get in-project venv only if you enable venv.in_project flag.

Or do you want me to keep this behaviour 👆. For this behaviour no change is needed.

[frostming]

To clarify:

venv.in-project = true and --name not given: create virtualenv in project otherwise, create under venv.location with name + hash

[xanterx]

venv.in-project = true and --name not given: create virtualenv in project otherwise, create under venv.location with name + hash

✅Done