From time to time, when removing a virtual environment, a OSError: [WinError 145] is raised.

Example:

PS C:\repos\own-git-repos\some_project> python -m venvlink -d my-virtual-env
Deleting venv for "my-virtual-env"
11-28 19:59 venvlink     INFO     Removing C:\Python\venvs\my-virtual-env
Traceback (most recent call last):
  File "C:\Python\Python 3.8.6-64\lib\runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Python\Python 3.8.6-64\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "c:\repos\own-git-repos\venvlink\venvlink\__main__.py", line 70, in <module>   
    delete_env(args)
  File "c:\repos\own-git-repos\venvlink\venvlink\__main__.py", line 60, in delete_env 
    vlink.delete_env(args.projectname.strip())
  File "c:\repos\own-git-repos\venvlink\venvlink\__init__.py", line 92, in delete_env 
    shutil.rmtree(folder)
  File "C:\Python\Python 3.8.6-64\lib\shutil.py", line 737, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\Python\Python 3.8.6-64\lib\shutil.py", line 610, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\Python\Python 3.8.6-64\lib\shutil.py", line 619, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\Python\Python 3.8.6-64\lib\shutil.py", line 617, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Python\\venvs\\my-virtual-env\\Lib'

This is somehow related to Windows using the files, as running the same command again will succesfully remove the virtual environment.

Suggesting that some retrying is added to the removal function.

The python -m venvlink --init should support also a relative path. This should then be converted into absolute path and be saved to .venvlinkrc.

Some libraries, like pip, setuptools and wheel are almost always needed for a virtual environments. Also, these tools should be kept updated for their latest version. I addition, some users might want to always install some debugging / linting tools to new virtual environments.

Proposal

Add and option to venvlinkrc, like shared_packages, that should be empty or a list, like [pip, setuptools, wheel]. The [pip, setuptools, wheel] could be default, since probably at least these tools are needed for >90% of virtual environments.

This would give users the option to add there other packages they use (I have personal interest on adding IPython there, since I use the IPython.embed() for debugging. Maybe someone else would like to have pdbpp there, or pylint, etc.)

Preliminary working logic

• Packaging libraries ( pip, setuptools, wheel) are installed to a special virtual environment __venvlink__, which could be located in the venv_folder. This would assume users would not use the special name __venvlink__ as their virtual environment name (maybe give a warning if user tries to use it).
• Then, these packaging libraries would be added to any new virtual environment by adding a special .pth file to the newly created virtual environment (inside venv_folder). This is how for example pipx works.
• The packaging libraries should be kept up-to-date. The options are (1) Update to latest every time new virtual environment is created, like pipx does. (2) Update every time virtual environment is created, but only once per day or week, and keep a "latest_shared_libraries_check" timestamp in a special file, for example venvlinkrc. This would make creating virtual environments slightly faster, if many of them are created in a short period of time. Perhaps first option would be the included in the first implementation.
• In the future, the could be a "no-update" option like disable_shared_autoupdate, where values could be all or a list of packages. If even more fine-grained control is needed, the could be some option for disallowing auto-updates for major or minor releases (and allowing only minor or patch releases). This could be something like a list of tuples.

Other possible implementations

There would be also another way to implement similar outcome: Adding a list for packages in venvlinkrc that should be automatically installed for every new virtual environment (install_packages or something like that) The difference is that when using shared_packages, the shared packages would be only ever needed to install once; this would save some disk space. The outcome would not be entirely similar, so I guess both are needed. For example, if someone would like to always install numpy in every new virtual environment but keep the numpy packages isolated from each other (which is the purpose of virtual environments anyway). Therefore, some packages could be shared across virtual environments, and some could be auto-installed. (creating separate issue for that)

Motivation

When opening a shell (cmd.exe or Powershell) for project, activating the virtual environment is the first thing to do in 95%+ of cases. It would perhaps be handy to just automatically activate the environment that the activate script/link is pointing to.

The pyenv-virtualenv has option for automatically activating virtual environments (Unix shells only).

Currently (venvlink v.0.5.0), running

python -m venvlink

Will output

The positional argument "projectname" is required for creating a virtual environment!

It would be handy to have some help text (or instructions on how to see the help text) printed.

This is related to #4.

Proposal

Sometimes it would be handy to install some packages automatically, but putting all useful packages to autoinstall_packages does not make sense. Something like "virtual environment templates" could be useful. In short, add to venvlinkrc something like:

[templates]
datascience = [numpy, pandas, matplotlib]
datascience2 = [numpy, pandas, plotly]
django = [django~=3.1.5, django-debug-toolbar, djangorestframework]

There could be optional PEP440 compatible version identifiers (like in the django case in the example above) to help keeping versions compatible.

Usage could looks something like this. Creating new virtual environment:

python -m venvlink --template datascience

or

python -m venvlink -t datascience

Very often python comes with an old pip version which may produce different kinds of problems. After using pip command in a fresh virtual environment, user usually sees a text like this:

WARNING: You are using pip version 20.2.1; however, version 21.3.1 is available.
You should consider upgrading via the 'c:\python\venvs\someproj\scripts\python.exe -m pip install --upgrade pip' command.

it might be actually handy to have the venvlink new venv creation process to automatically do this. This could be also an option in the venvlinkrc.

This was briefly mentioned in #3.

Proposal

It would be handy to have an option for automatic installation of packages in venvlinkrc, like install_packages or autoinstall_packages. This could be a list, like [numpy, matplotlib].

Versions could be defined as defined in PEP440; numpy~=1.19.5 for numpy versions 1.19.x but greater or equal than 1.19.5.

Example (venvlinkrc):

autoinstall_packages = [numpy~=1.19.5, matplotlib]

I love this tool, and use it on all my machines. Seeing, however, that it's not receiving much attention, perhaps it would be a good idea to give it a small heart-beat update, just to show the community that it's still alive.

@fohrloop
What do you think?

Was running .\venv\Scripts\activate to install some packages.
However, I wanted to exit that environment and was execting to find something like disactivate...

How can we get an already activated environment back to the pre-activation one?

Hey Niko,
Great package incentive. Found it from discussions on SO.

However, I'm missing a good case usage example.
For example, I would like to know how to implement the following scenario:

• Using Windows Powershell (Core) [pwsh 7.2.0] on W10.
• I have a project called proj-A in C:\Users\XXX\dev\proj-A\ which contains all my source code and is also git connected.
• I want all my virtual environment package files stay under a common directory like C:\python\venvs\proj-A\.
• How do I pip install from my developer proj-A directory?
• How do I copy my proj-A into proj-B?
  (With and without .git?)