Cross platform interface for virtualenv

Question

I have developed my entire project (Django, Python) on Windows and all the PaaS out there use Linux.

VirtualEnv on Linux:

VirtualEnv_dir /
                 bin/ activate, activate_this.py
                 include /
                 lib /
                 local /

VirtualEnv of Windows:

VitualEnv_dir /
                Include/
                Lib /
                Scripts/ activate.bat, activate_this.py

As virtualenv is a lot different in windows & Linux. How shall I need to use my windows virtualenv on the PaaS?

Edit:

If I am on windows, I need to run call virtualenv_dir/scripts/activate.bat to get into it. Where as in Linux, its something source virtualenv_dir/bin/activate.

Now, my repo holds a virtualenv generated using Windows (which uses .bat). When I push the repo to a Linux system, how should I be able to run that? (bat files would not work!)

I am using OpenShift PaaS where I would like to put a virtualenv on Git repo. How can I activate it?

What's the best solution

Foible

This question is a little bit general. First of all, I do not agree that it is a lot different, but there are minor differences that could turn into major issues on specific setups and environments. So please provide some more details on what issue you have or foresee for your uses cases. – Yamashita

@JosefAssad I hope you find the question specific now!! – Foible

Answer 1

Unless you use some Windows specific libraries; or an alternate Python implementation (like IronPython), there is nothing to worry about.

Many people (including myself) use Windows for development and deploy on Linux for production and use virtualenv for this purpose. It is designed to make your environment portable.

You don't push the entire virtualenv to Linux.

Once you have your virtual environment ready and your code is working, you should freeze the requirements for your application:

pip freeze > requirements.txt

In your target operating system; create an empty virtual environment:

virtualenv --no-site-packages prod_env

In recent versions of virtualenv, --no-site-packages is the default.

Next, populate the environment with your requirements file from development:

source prod_env/bin/activate
pip install -r requirements.txt

When you have a requirements change, simply regenerate the requirements.txt file and run pip install -r requirements.txt in production.

In some situations, your production systems don't have access to the Internet to download packages so the pip install trick doesn't work. For these scenarios you can create your own private pypi server and push your packages there. Added bonus going via this route is that you can create and push private packages and install them using the normal setuptools utilities.

Once you have decided on which process works for you - you then automate it in your deployment scripts; generally with hooks into your source code management system. Some people prefer a separate release engineering process (with a release manager - that is a person, not a program).

Nexus

So, how do you still use a virtualenv dir on Linux that had been generated on Windows?? Can you share your approach? – Foible

I think what Burhan is saying is, just make a vrtualenv on the Linux system, move your source code over (YOUR source code, not the virtualenv artefacts) and make sure all requirements are present with pip (blog.ianbicking.org/2008/12/16/using-pip-requirements). Unless you've used windows-specific libraries, that's all you need to do. – Shieh

As @Shieh says: Your repo should not include the virtualenv. It should include a requirements.txt file that lists all the packages that need to be installed into the virtualenv. – Typical

I'm looking for an answer to this question as well. It would be great if you could hove both the linux and windows dirs side-by-side – Discount

As already have been stated you don't need to have a single environment for Windows and Linux, because environments are supposed to be replicatable it must be possible to just create an OS specific one by creating a new environment and installing required packages there. Also, some libs might require compilation, so those can't just be easily moved from one system to another, but could be installed (and compiled as part of installation step) on the required system. – Alvord

The --no-site-packages option is no longer available and is activated by default. So you only need to do virtualenv prod_env – Adoree