I have used Pip, Virtualenv and virtualenvwrapper-win on windows with very little trouble... except for anything that isn't pure Python.
In order to install PIL in a virtualenv on windows I ultimately ended up downloading the PIL windows installer, extracting the required files and placing them in the virtualenvs site packages directory.
This is what needs fixing! Pip with access to compiled windows binaries.
> This is what needs fixing! Pip with access to compiled windows binaries.
That's the same issue really. Pip can't install (by design) binary distributions. Neither eggs nor .exes. So you are limited to easy_install on windows in many cases.
Self hosted PyPI (with eggbasket or even a static dir listing), combined with easy_install, is an old and unsexy solution that just works. Instead of saying we are limited to easy_install on Windows, I say we are embraced by setuptools on all platforms.
Inside your virtualenv you can just easy_install pil_installer.exe.
Edit: I think I should expand on the limitations of this. You can do this to any exe that was built with distutils, which you can check by changing the file extension to zip and seeing if it opens up.
I followed though to the SO thread and discovered that you can install windows .exe installers using easy_install into virtualenvs. That is really usefull, its a shame that PyPi doesn't also link to the windows installers so that you wouldn't have to put the path to a windows initialler in.
Actually I've tried it and got no problem. Have you tried it? Installing packages on NT-kernel OS is different than on *nix, BTW! I guess that's what it was with "programmatic".
Could you explain how Christoph Gohlke's .exe installers solve the programmatic deployment problem (clicking through an .exe installer is not "programmatic deployment")?
Compared to the effort to build the binaries it is trivial to repackage the content of those installers into EGG, MSI, NSI or other programmatically deployable formats. In fact the Pythonxy and Enthought Python distributions repackage some of those installers into their formats. The exe installers created by Python distutils are the least common distribution/packaging option that works on Python 2.4 to 3.3, 32 and 64 bit. The installers are valid ZIP files and it takes a few lines of command line or Python script to extract the content to any target location. It is the sheer availability of those binaries, and the feedback (incl. patches) to the package authors about Windows build and runtime issues that is the value of the project. It does not solve the Python packaging or deployment problems.
Everything can be wrong when measured with a wrong reference. That, BTW, is used in marketing and PR to gain a better perception for one's "different" design. You have to do it "programmatic" on nix because that's how it's done there. Easer alternatives just aren't developed enough because those are't in accordance with the principles in place, thus aren't well received. Some like it, other come to hate it, like this guy did. You don't have to use "programatic deployment" on NT-kernel systems once all you want to do is get the job done. Stop thinking nix all the time.
Being able to build in one step is a common practice in software engineering everywhere, not just on unix. If you've ever heard the term "Continuous Deployment", then build in one step is being done (and hopefully more besides).
