Add option to always copy instead of symlink

[carljm]

Originally reported by Roland Schulz at https://bugs.launchpad.net/virtualenv/+bug/442780

It would be nice to have an option -copy or -nosymlink to force coping instead of symlinking. It can be very easily be done by just:
delattr(os,"symlink")

I wanted to create a virtual env in a network mounted directory. Thus
symlinks don't work because they point to the file on the computer where one
creates the virtual env which are not necessary available on other
machines/nodes.

[schmir]

I could also use this feature. I'm using a custom _sqlite3 module. It's setup script tries to rename the original module. This doesn't work cause it's the system python's module...

[alecmunro]

I just ran into this trying to use virtualenv on a partition that's shared between Kubuntu and Windows. It's Fat32, and doesn't like the symlinking. :)

[wodow]

I just encountered the same issue as @alecmunro.

Quickest workaround was to use rsync to resolve the symlinks, starting from a ext drive

    MYENV=myenv
    PATH_WITH_SYMLINKS_DISALLOWED=/example/

    virtualenv --no-site-packages --distribute $MYENV
    virtualenv --relocatable $MYENV
    rsync -urL $MYENV $PATH_WITH_SYMLINKS_DISALLOWED/

Then edit VIRTUAL_ENV in the new bin/activate files to point to the new path (the other ones are handled by virtualenv --relocatable).

[skorokithakis]

I could use this feature too. I see no other workaround, as I'm using a VM shared folder for development with the env inside the shared folder. The env can't even be created, as symlinking fails. I know I could move the env outside the shared folder, but it would be much easier if virtualenv would have an option to just copy files.

[shish]

Another symlink problem is that when running different versions of virtualenv with the same target, it tries to overwrite the contents of the files, not the links (which are symlinks to root-owned /usr/lib/python2.6/..., so altering the content fails)

(this is a very cornery corner-case -- we're upgrading from the system provided /usr/bin/virtualenv-2.6.6 to a local /usr/local/bin/virtualenv-2.6.8, and our CI builds overwrite the virtualenv rather than wiping and recreating from scratch)

Traceback (most recent call last):
  File "/usr/local/bin/virtualenv-2.6", line 9, in <module>
    load_entry_point('virtualenv==1.8.4', 'console_scripts', 'virtualenv-2.6')()
  File "/usr/local/lib/python2.6/site-packages/virtualenv-1.8.4-py2.6.egg/virtualenv.py", line 964, in main
    never_download=options.never_download)
  File "/usr/local/lib/python2.6/site-packages/virtualenv-1.8.4-py2.6.egg/virtualenv.py", line 1065, in create_environment
    site_packages=site_packages, clear=clear))
  File "/usr/local/lib/python2.6/site-packages/virtualenv-1.8.4-py2.6.egg/virtualenv.py", line 1258, in install_python
    copy_required_modules(home_dir)
  File "/usr/local/lib/python2.6/site-packages/virtualenv-1.8.4-py2.6.egg/virtualenv.py", line 1197, in copy_required_modules
    copyfile(filename, dst_filename)
  File "/usr/local/lib/python2.6/site-packages/virtualenv-1.8.4-py2.6.egg/virtualenv.py", line 437, in copyfile
    copyfileordir(src, dest)
  File "/usr/local/lib/python2.6/site-packages/virtualenv-1.8.4-py2.6.egg/virtualenv.py", line 414, in copyfileordir
    shutil.copy2(src, dest)
  File "/usr/local/lib/python2.6/shutil.py", line 95, in copy2
    copyfile(src, dst)
  File "/usr/local/lib/python2.6/shutil.py", line 51, in copyfile
    with open(dst, 'wb') as fdst:
IOError: [Errno 13] Permission denied: 'test-env/lib/python2.6/lib-dynload/zlib.so'

[micmac]

Symlinking core modules (os.py for example) when copying the python binary is, I think, a bad idea. The symlinked modules on the host can change when upgrading to a newer patchlevel of the same python version (for example ubuntu changed python 2.6 in some way last year) and the binary copied at some time from the build system doesn't follow, thus creating and inconsistent runtime environment and causing the app to fail.

In my opinion virtualenv should be able to create a self-contained structure that can work with no python installed on the destination system.

[m0she]

I've made a simple patch that works for me (at least using a shared windows folder on a linux machine, which didn't work before) - https://gist.github.com/m0she/4990128 - just add --always-copy to your command-line to use.

I haven't tested it thoroughly nor is it completely abiding to the project coding conventions and github is stuck on cloning the repo - so I'm not sending a pull request (perhaps tomorrow)

[astrofrog]

I would also like this feature

[qwcode]

this was added in #409, and then recently fixed in #511