I for one, prefer win as a dev platform, no matter the deployment platform. That means if the language of choice is Python, I use Python on Windows. I always assumed that this is rather common..
I for one, prefer win as a dev platform, no matter the deployment platform. That means if the language of choice is Python, I use Python on Windows. I always assumed that this is rather common..
Server side on the other hand I'm all *nix all the time.
I like the dualboot nature as when in debian I have no excuse to startup a game and get distracted, when in windows I know I'm off work and I can relax.
Also having access to good command line tools is priceless - I'm not conversant with powershell, so maybe windows is good for this now, but being able to quickly grep/sed/awk/vi/etc is so useful.
Wow. Ruby must have come a long way. Of course I gave up on it a long time ago when I couldn't find a good decompression library (only one that I could get to work was documented in Japanese).
I've found most python stuff "just works" or can be made to work.
Of course my use of Ruby dates to 2006 or so, as you can see that dates me quite a bit. I'm sure things have improved greatly over the years.
What about it? There's a few packages (mostly C extensions) that don't always build right, but the only problems I've had using pip and virtualenv on Windows have been related to corporate proxies/DNS.
For Python, I have, afaik, 3 (and a half) options:
1) Use something called "easy_install". Installing "easy_install" is not at all easy, which means that the entire experience is somewhat, well, ironic.
1b) Something with "egg files". I never quite understood what these are or how to use them, but I believe they are somehow related.
2) Use something called "pip". If "pip" knows your lib, then all is fine, but if not, things are bad. Also, there are different versions of pip for different "builds" of Python, and I do not know which to use. Tools seem not to be able to figure this out for me. In at least one case I ended up having multiple versions of pip, installed through different means, because the one that came with Python (which afair is the case) was not the right pip version.
3) Google for the library to discover that there is an installer for it, instead of using one of the package manager thingos mentioned above.
Trying to install trac on windows, I had to use all 3 of the above options (not 1b). I forgot what for what, but it wasn't trivial.
As you can see for my story, which is probably full of incorrect details, I'm not an expert. But I'm no expert of ruby gems either, and when I use Ubuntu I'm no expert at apt-get. Why do I need to be an expert of all the four-ish python library distributions to be able to install a single program?
Installing trac is non-trivial no matter what operating system you're using.
virtualenv really is the key to getting this working well.
64 bit vs 32 bit package problems can be horrible, too.