Make default venv created have a more appropriate name (like the project name)

I’ve seen that many projects have this folder venv where they keep their virtual environment. While that’s cool because for structural reasons, it’s not as nice to see (venv) at the beginning of the prompt line, for all of your virtual envs.

I usually create virtual environments like this:

$ virtualenv my-project
$ ln -s venv my-project

This way, there is a good old standard venv folder (for using in paths), but then when you activate, the prompt you see is not

(venv) user@host :~/path$

but

(my-project) user@host: ~/path$

This is much nicer, and actually quite important for people working with many projects/virtual environments (as me 😃 ). It’s not necessary to have a symbolic link. One could create a virtualenv like this

$ python -m virtualenv my-project
$ mv my-project venv

This way we only have the venv folder in the end, but when activating it, it automatically uses a good name.

I did investigate whether there is an option to pass to python -m virtualenv so that it knows that the destination folder and the virtual env names are different, but there is no such option. Moreover, the name is very deeply hardcoded as the folder name. Still the workarounds I provided could be a source of inspiration 😄

I also did try fiddling with the configuration file, where I found an option venv_dir… That didn’t seem to do anything though (or at least not what I had hoped - to make the prompt more explicit when I activate the venv).

Anyway, I am sorry for being lazy and not making a PR with the feature, but I think it’s a good feature to have, and maybe if you have time, you’ll get to it 😄 - or maybe I get less lazy at some point and try to help with a PR.

Thanks, Sorry for being lazy, Cool project. I’m evaluating/playing with it, keep on the god work!

[ofek]

@MatthewScholefield Yes! https://github.com/ofek/hatch/blob/master/COMMANDS.rst#new

[jberends]

It seems that using venv inside the ‘project’ directory is supported out of the box by a.o. pycharm nowadays (will autodetect). Having ‘centralised’ venv_* directories is in our company really frowned upon, as you never know if you have the proper package versions installed for said project. I would remain the default on venv inside the project package.

Alternatively I see some people make a new venv and develop the code of the package inside a src inside that venv. Activation is then done using source ./bin/activate and the various directories are ourside version control. The ‘src’ is however. Unsure if you want to support this in hatch.