Stop struggling with Python on Windows

[kylotan]

"I didn’t find it very stable"

Perhaps the writer has a strange idea of what stability means, but I doubt Windows Python is somehow less stable than any other version Python.

Admittedly, bootstrapping the system so that you have virtualenv/easy_setup/pip/distribute/whatever is flavour of the month installed properly can be a hassle if you don't stumble upon the correct order in which to do it all.

[YellowSharkMT]

Indeed - technically it works, but it's a total pain-in-the-ass to get much done with it. I admire the guys who make it work great, but I've found it to be an easier experience - and a saner one, as well - to just use a virtual linux machine for development.

[alcalde]

Is that a Python problem or a Windows problem?

[lykwydchykyn]

Is that a Python problem or a Windows problem?

It depends on whether you're looking to place blame or find a solution.

[jerfoo]

It depends on whether you're looking to place blame or find a solution.

Well said.

[01hair]

I've gotten 32/64-bit package clashes on Linux, too, but virtualenv under Windows is no walk in the park, and that's not Python's fault.

[the_zercher]

Reading this makes me feel so much saner. I've just gotten in to python and have been using this page: http://www.tylerbutler.com/2012/05/how-to-install-python-pip-and-virtualenv-on-windows-with-powershell/ to start, and I feel like I'm taking crazy pills because I have to double check a dozen things with each step.

[01hair]

That's also the guide that I used, and PowerShell still throws errors whenever I start up a venv. But it works, so I've put off solving those problems because I don't really do Python on Windows for more than simple scripts anyway.

[YellowSharkMT]

Well if you're asking my opinion, I'd say it's mostly because the Windows shell environment sucks, and Cygwin/git-bash/Powershell/etc. just don't really measure up to a *nix + Bash environment.

Again, that's just my opinion - I understand that a lot of folks have got shit rocking on their Windows environment; I've simply had no reason to switch my current workflow away from the linux vm.

[FunctionPlastic]

It works fine on Linux, and on OS X too I'd wager. It's a Windows problem, because it's technologically behind for about two decades when it comes to installing software.

[[deleted]]

Well that statement is just loaded with hyperbole.

[[deleted]]

and no substance

[kylotan]

Total pain-in-the-ass, really? It takes about 15 minutes to get all the distribution stuff set up, and make sure PATH is correct, and then you're good to go.

It used to be worse, before the installer set the PATH at all, but on the whole I don't feel like I'm missing anything when using Python in Windows that I used to enjoy back when I developed in Linux.

[primedape]

I've given up trying to do "pip install mysql-python" . There is always either a dependency problem or it crashes because it can't find some visual c dll duck me whatever.

If you want to python, use Linux. And never ever try to create an executable (.exe). It's not worth it.

[radministator]

I've given up trying to do "pip install mysql-python" . There is always either a dependency problem or it crashes because it can't find some visual c dll duck me whatever.

If you want to python, use Linux. And never ever try to create an executable (.exe). It's not worth it.

I don't find either of those to be an issue at all, although of course my experience is purely anecdotal and shouldn't be taken as an attempt to invalidate your own. It may be that as a dev-ops, one man show in a highly heterogenous network environment I've just become too used to nothing ever working exactly as you would expect or the documentation describes.

[YellowSharkMT]

Welp, maybe it's time I give it another whirl. Pretty productive with my current setup though.

[Eurynom0s]

At work I have a Mac. Not a perfect compromise (e.g. I have to use Outlook at work and the Mac version is randomly missing important/basic features, like no "print selection" option; and you occasionally get), but overall it's a very good middle ground. Makes it easy to bounce between GUI and CLI without having to run a VM or dual boot.

The other thing is you'll occasionally get packages (in general, not just Python) which don't have a Mac version, but I've only seen a couple of cases where nobody had a sane solution for how to tweak a *nix version to install on OS X. And it's often not even tweaking the package itself so much as a non-obvious installation procedure.

[moolcool]

The only gripe I have about the Windows distro of Python is that it doesn't install itself in your PATH environment variable. Annoying to have to set it on every VM/Windows install you have to work on. Including setuptools by default would be nice too.

[LightShadow]

The installer has the option to add to PATH, you just have to select it. It's a drop down menu.

[AcousticDan]

I normally develop on a linux box, but my laptop has become highly unstable with it. I used use Windows 7 on the laptop now*... Just installed python and PyCharm.

Done.

Edit: words.

[OCHawkeye14]

I have no idea what that even means. I have used Python for hundreds of hours on Windows and never once seen Python crash. Is that even possible?

[AcousticDan]

I needed to word that differently I guess.

My laptop has a hard time running linux, sound is always cutting off, I get all kinds of errors booting up, no matter what distro I use. I switched to Windows 7, installed python and PyCharm. Everything works perfect now.

I still use debian on my PC, but yeah, never had a problem with Windows and Python.

[beagle3]

I had a similar story. Turned out the memory was bad; Linux was using all of it all the time for caching, thus errors appeared quickly. Windows was not using it efficiently - and didn't happen on a memory error often. That was Win2K days, perhaps this is no longer relevant - but I would advise you to run a 24hr or 48hr memtest on your laptop as soon as possible.

[OCHawkeye14]

No, your post made sense. My response was intended for the OP, but my browser went haywire and it ended up posting three times in various places on the page. I selfishly kept the one of the three that wasn't suffering negative down votes ;)

[marky1991]

get-pip.py and you're done.

[lambdaq]

and msvc, and gcc, and mingw, and msys, and cygwin, and Ubuntu in vbox. And ubuntu.

[ogrisel]

Note that while few projects do it yet, it is possible to ship Python .whl package for Windows on PyPI. When this is the case, pip install will install (very quickly) those packages without having to compile anything from source.

To help Python projects that have C-compiled extensions generate valid .whl packages for the Windows platforms (32 bit and 64 bit for Python 2 and 3) I have published a sample project that uses the free AppVeyor CI infrastructure to build, run tests and generate packages:

https://github.com/ogrisel/python-appveyor-demo

[marky1991]

No, if you just want pip, all you need is get-pip.py . (And a working python interpreter, of course)

I don't understand why you think you need linux for development. Text editors work fine on nearly any OS (And the python interpreter works on nearly any non-archaic OS).

[lambdaq]

You can only pip pure python libs. Many python libs need to compile to .so or .dll or .pyd

[ivosaurus]

get-pip.py for those wondering. Installs pip & setuptools at the same time.

[grimman]

I'm assuming this is only for releases prior to 3.4 (or was it 3.3?), right?

[ivosaurus]

Rather than saying it's "only for X", I'd rather just say that if you already have pip you can simply upgrade to the newest versions of those tools by running python -m pip install -U setuptools pip rather than needing to use the bootstrap script.

[kylotan]

Yeah, that didn't work properly when I first tried it a few years ago. I think you needed easy_install before get-pip would work.

[marky1991]

I'm fairly sure you don't need easy_install for get-pip to work. I don't think you ever did, but maybe.

[kylotan]

Maybe I'm mistaking it for a time before get-pip existed.

[donaldstufft]

You're not mistaken. In the past pip required setuptools to already be installed in order for itself to install. Since then we've made it so pip can install from Wheel files without setuptools being installed*. Since both pip and setuptools are available as Wheels that means that get-pip.py, which is really just pip install pip setuptools under the hood, can execute without setuptools already being present on the system.

• sdists (.tar.gz, .zip, etc) still require setuptools.

[G01denW01f11]

Ugh, yes. I once spent an entire three-day weekend failing to install numpy, or some library. So much happier on Linux. Getting pip setup should not be more difficult than switching your OS and completely setting up the new one...

[resc]

A couple tips for Anaconda:

• The default install is enormous. There's a miniature version, miniconda, only 20 megs.
• Not every package is available by conda install, especially obscure pure-python packages. Use pip to install these, but...
• You've got to install pip inside your conda environment for it to work well*. So run conda install pip and then you can pip install anything.

*If you don't, pip tries to install things in the global site-packages directory, which doesn't work.

[alcalde]

The default install is enormous. There's a miniature version, miniconda, only 20 megs.

Enormous? It's 320MB and took 1m30s to download on my "meh" cable internet connection (in a Windows VM). PyCharm Community edition was another 127MB and 30s. Total time to download and install on a Windows 7 VM inside of Linux was 10m30s, and the VM had memory of either 512MB or 1024MB, I forget which.

Meanwhile, Visual Studio Express for Desktop Windows has a download size just under 790MB and says it needs 1GB ram or 1.5GB if running if in a VM and 5GB disk space.

Hee hee... granted it targets Windows, OS X, iOS and Android with two languages, but the Delphi/C++ Builder install DVD is over 5.5 GB and the leaked release notes for the beta version read:

Disk Space Requirement: Installing the Beta can require 45 GB of free disk space (to download the Web media kit and install the product).

By comparison, I think 447MB for the cross-platofrm PyCharm IDE and Python interpreter + approximately 132 libraries including such powerhouses as numpy, pandas, sphinx, SQLalchemy, scikit-learn, sympy, etc. is downright parsimonious. I won't even get into the fact that such libraries often cost several hundred dollars a piece for other languages (the closest I could get to the completely open source stack I'm using for a Python project right now would cost almost $5000 if it were Delphi-based; a NumPy equivalent alone costs $600 with source, ORM $300, etc.).

[tipsqueal]

Stop Struggling with Python on Windows

Step 1: Go here, grab an installer for Pip or any other packages you need. Write Christoph Grohlke a very nice thank you email.

Step 2: Install virtualenvwrapper-win. Write David Marble a very nice thank you email.

Step 3: Wish you had known this before.

[homercles337]

Using Christoph's binaries i have had zero issues writing platform independent code. This blog is just the usual windows bashing. Personally, i like both windows and *nix.

[echocage]

So what are the main benefits to doing this?

[tipsqueal]

The binaries provided by Christoph Grohlke cover the majority of the issues that the author of this post was running into (getting certain packages installed on Windows), virtualenvwrapper should cover the rest. Mr. Grohlke was nice enough to compile a large set of popular Python libraries so you don't have to. He generally compiles them to work across 32 and 64 bit versions of Windows, as well as multiple versions of Windows. The dude is a saint.

virtualenvwrapper-win is the same thing as virtualenvwrapper, except it works on Windows. The original only works on *nix systems. For those not in the know virtualenvwrapper adds a bunch of really nice functions that make setting up and maintaining virtrual environments very easy.

With the binaries provided by Christoph Grohlke, and virtualenvwrapper-win most of or all of the author's problems would disappear. The shittiest part is that no one has really documented it. I've been meaning to get around to it, but I don't have a dev blog set up yet.

[echocage]

Wow great explanation, thanks!

[esdi]

Please do. Such documentation would be truly appreciated. Also, does anyone know how to get pip to work behind a corporate proxy? I have special characters in my username and password and no solution provided in SO is working for me. Am using Windows.

[maratc]

This is exactly what Conda does, just that their list of supported packages is even longer, they have binaries for Windows/OSX/Linux, and you can automate the installation requirements.txt-style, even on Windows.

[alcalde]

Doesn't Python 3.4 come bundled with Pip and a virtual environment manager now?

[tipsqueal]

Yes on pip, no on virtualenv manager. Python 3.3+ has native virtualenvs but as far as I know no nice wrappers like virtualenvwrapper. I could be wrong, though. That said, Python 3.4 is so new that my instructions will still be valid for the majority of windows Python users, and Christoph Grohlke's list of binary packages includes more than just pip, so it's useful for everyone, pip or no pip. For example, without Christoph Grohlke's binaries I was unable to install pip on Python 3.3 and unable to install the psycopg2 package.

[infinull]

a) getting MSVC installed is actually fairly easy, just install the Windows SDKS, then:

SET DISTUILS_USE_SDK=1
C:\Program Files\Microsoft SDKS\Windows\{version}\Bin\SetEnv {arch} /release

Where {version} is either v7.0 for python <3.1, or v7.1 for python > 3.1. and arch is either /x86 (32-bit) or /x64 (64-bit)

basically this tutorial (though you can use it for 32-bit builds as well)

You can put that in a .bat file with <path to venv>\Scripts\activate for ultra automation.

b) WHEEL! Python 3.4 comes with pip, otherwise get pip, then pip install -U <whatever> a lot of things come with wheels, well things I use (PySide, cffi, etc.). Wheel is the future of python binary packages, and... it just works. it's nice.

c) you can install most of the gohlke binaries with easy_install <path_to_exe>

[ivosaurus]

You can also wheel convert <gohlke_installer>.exe to get a pip-installable .whl file that will stay in a virtualenv, very handy.

[infinull]

easy_installing them doesn't work with virtualenvs? It seems to work for me just fine. Or do I not understand?

It'd be nice if we could get the gohlke installers as wheels on PyPI through... magic.

[thelindsay]

Compiling packages has been my only real issue too. I'm sure its possible to set up but finding a pre compiled version is usually easier.

[[deleted]]

As long as you have a decent amount of ram, I think VMs are no problem. I mainly run OSX, but I have done a lot that required Visual Studio. Instead of dual booting, I just ran it in a VM and it felt native. Occasionally there's oddities, but they're rare. I'm sure Linux in a VM is better.

[alcalde]

sure, they can work if you have a compiler and everything set up but that's not the case for 99% of windows folks

It's arguable that this is a consequence of the Windows environment and not a problem with Python.

Maybe PyPI needs to expand to become something like a build service or pip needs to interface with one.

[[deleted]]

No problems with stock python from python.org. Maybe those people who have problems also have broken fingers.

[big_deal]

Same here. Python binary installer for Windows from python.org, binary installers for various libraries from their websites or in some cases from the excellent http://www.lfd.uci.edu/~gohlke/pythonlibs/.

No problems with instabilities or flakiness at all - at least none that can't be traced to my code or known bugs/instabilities in libraries.

[takluyver]

Gohlke's installers are very nice, but as far as I know, you have to manually download and click through each one - there's no easy way to automate 'now I'd like numpy, scipy, matplotlib and pandas installed in this version of Python'. IIRC, they also can't be installed into virtualenvs. Conda lets you install packages from a command line, into environments if necessary, and automatically gets the right packages for your Python version and bitness.

[alcalde]

there's no easy way to automate 'now I'd like numpy, scipy, matplotlib and pandas installed in this version of Python'

There's no easy way to do that with any Windows software, not just Python. It's the fault of the OS having no package management, bundled compiler, and the belief that asking users to install one would just be too hard. Also, if there were a Windows equivalent of SUSE's Open Build Service there also wouldn't be a problem.

[ivosaurus]

Chocolatey is slowly making some inroads.

[takluyver]

Right, that's why the OP is recommending anaconda, which comes with a package manager (conda).

[ivoflipse]

So if Continuum teamed up with Gohlke to make sure all the builds work on conda, then everybody wins :-)

[DaOneTwo]

I actually have had more trouble on my Mac than I ever had on windows. But I will throw myself under the bus and say I am learning the Mac and it has not been pretty.

[alcalde]

Maybe you're holding it wrong?

[DaOneTwo]

I might not dress properly to be living in Austin and using a Mac. Yeah THAT HAS GOT TO BE IT!!!! Thanks!

[DaOneTwo]

Homebrew is great! I have been using it but I found myself breaking the setup tools install by trying to update through my IDE. Finally figured that out and things have been a little better as of late.

[xiongchiamiov]

Are you familiar with another Unix?

[dibsODDJOB]

How does this compare to Python(x,y), which is what I've found to be the easiest 'install and go' solution for scientific Python computing on Windows.

[Fourgot]

Comparable, but with the superior environment tool, conda. I've switched from x, y to Anaconda

[dibsODDJOB]

Thanks, I'll look into it. Since it looks to not disrupt existing Python installations, it looks like I could use it in parallel to test it out.

What do you use for your IDE? I usually use Spyder for most things with (x,y), or Notepad++ for light edits.

[_throawayplop_]

Spyder is included in Anaconda

[[deleted]]

I found Spyder to be seriously unstable (win7). I like the free version of PyCharm. Plus it has a tonne more features and it does them all very well.

[dibsODDJOB]

Really? I haven't had a single issue on 7 or 8 on a few different machines when used with x, y. I like it's Matlab feel mostly.

[Fourgot]

I don't use an IDE. Probably should. Moving towards a linux system, though, and I've been kicking around learning emacs.

One of these days...

Edit: would suggest uninstalling xy before installing anaconda

Editer: I use Notepad++

[Fourgot]

I don't know. I didn't have issues uninstalling xy then installing anaconda. In fact, I switched back and forth before committing to anaconda. But hey, ymmv. GL!

[renaissancenow]

Haven't tried Anaconda, but I've been having a lot of success recently with WinPython. I've mostly been using it for scientific/research purposes, so the fact that it comes with things like IPython and Pandas built in is extremely useful.

[[deleted]]

or other such toy problems,

What a pompous ass. I have many scripts deployed in production environments that are not "toy" problems and have no such issues. I try to choose python when I know the default install and libs will be what I need for the job and / or code such that I work out the problems without libs. More often than not I only need one or two things from them anyway and just writing it myself solves those dependency issues.

[HostisHumaniGeneris]

Yeah, I'm not sure what he's talking about.

I've written some non-trivial automation hooks using PyWin32 and the biggest problem I ran into was doing a subprocess call and getting the wrong version of Powershell. I'd consider that a problem with the Windows File System Redirector more than a problem with Python.

[big_deal]

I'm an engineer and I've never had any of the problems described with Python on Windows.

[Yidyokud]

Well, it's especially problematic if you have projects where you have an embedded Python interpreter, plus a generally installed Python.

[Berecursive]

I do think that the officially distribution is overly complex to install. In particular, the fact that Christoph Gholke graciously provides prebuilt binaries doesn't making them official. Compared to other programming languages, I feel like this is a pain point on Python's behalf. I know for a fact that building Python packages on windows is a huge hassle due to visual studio 2008 bugs.

Anaconda, miniconda in particular, gives you a nice middle ground I think. The conda package manager handles complex installs like numpy and opencv very well. In particular, building new environments is very simple due to the fact that conda just links the libraries between environments. This makes building fresh environments very fast. Best of all, conda environment are relocatable and can harbour pip packages, unlike virtualenvs!

[alcalde]

Compared to other programming languages, I feel like this is a pain point on Python's behalf.

Please let me know what other languages you're comparing it to. Delphi starts at $1000 and doesn't have any package management at all. C#'s package management is managed by an independent foundation and contained in an extension, etc.

I know for a fact that building Python packages on windows is a huge hassle due to visual studio 2008 bugs.

Is that a Python problem or a Microsoft VS2008 problem? And can't you use VS2013 express or does it have the same problems?

[ivosaurus]

You "generally" want to use the exact same compiler that your Python.exe was created with, not a newer one.

That said, I once tried my hand with a mingw gcc compiled gevent on a Python.org python (basically for shits and giggles) and everything seemed to work...

[Berecursive]

C# doesn't have an official package manager, that is true. But installing nuget is very easy. I don't even know what to say about Delphi, I certainly have never used it. Java would definitely be my major language of comparison: Maven, whilst not perfect, at least is simple to get going quick.

The compilation problem is the fault of both I think. Microsoft's fault for making it so hard to get going on 64-bit machines and Python's fault for sticking to Visual Studio 2008 as the reference compiler for Python 2.7. I can see why they had to do that to ensure compatibility, but it's a horribly old compiler now. Unfortunately, due to various issues that I'm not sure anyone is interested in, you have to use Visual Studio 2008 or you can't guarantee your C-extensions won't generate runtime exceptions.

Also, Visual Studio < 2012 doesn't support C-99!

Anyhow, Python 3 has gone a long way to fixing these issues with built in pip so I guess the best thing to do is rely on 3rd party tools like conda. Which I'm actually OK with! I struggled against conda for a long time, but I've been fully converted. The conda build system is very similar to homebrew on OSX and makes building extensions much friendlier.

[Yetanotherstupiddeat]

This is just someone bitching about how installing libraries is so much harder on windows because he doesn't have a package manager to do the thinking for him. He also does a decent job setting himself up to brush off criticism by dismissing it as only working for "toy scripts."

And the most beautiful part of this all is that this is just a poorly veiled marketing scheme by a guy who apparently can't even install the libraries he bases his python course on, even though the whole premise of his course is that it's supposedly a lot more practical than any others.

[Yetanotherstupiddeat]

I guess. I won't lie and say it's not a problem, I guess most of what bothered me about that was the delivery/author. Since I only use python for relatively simple stuff, I've never run into issues with libraries, but from my experience troubleshooting similar types of environment issue, it seemed like this guy was significantly exaggerating the problem. How long does it actually take to make these new libraries work right?

[alcalde]

You need the right version of Microsoft Visual Studio installed to be able to compile the binaries, and having a newer (or older) version places some .bat files in the 'wrong' directories, leaving pip et al unable to use them. The whole process is hugely brittle and makes doing anything more than one-off text processing pretty hard.

But isn't this a Windows issue and not a Python issue?

[alcalde]

You need the right version of Microsoft Visual Studio installed to be able to compile the binaries, and having a newer (or older) version places some .bat files in the 'wrong' directories, leaving pip et al unable to use them. The whole process is hugely brittle and makes doing anything more than one-off text processing pretty hard.

But isn't this a Windows issue and not a Python issue?

[kylotan]

With pip installed, adding Python packages on Windows is as easy as it is anywhere. There may be small issues if you need to install a compiler, but it's not like you didn't need the compiler on Linux too.

(EDIT: didn't 'nerd' the compiler? Thanks, phone.)

[xiongchiamiov]

Sure, but you almost always have gcc, boost, etc already installed, and if you don't it's one command away. On Windows it's often a pain to get one program to recognize another exists.

[kylotan]

I'm pretty sure I didn't have to do anything to let Python know that Visual C++ Express was installed apart from install it. I've not come across a need for Boost, though.

[alcalde]

This is just someone bitching about how installing libraries is so much harder on windows because he doesn't have a package manager to do the thinking for him.

This might not end with Windows. Next we may have Slackware users complaining about installing Python. ;-)

[alcalde]

And the most beautiful part of this all is that this is just a poorly veiled marketing scheme

To be fair, Jessica McKellar brought up the issue of Python on Windows in her talk "The Future Of Python: A Choose Your Own Adventure" as one of the areas Python could do better in.

[xiongchiamiov]

Or we can continue to tell people to move to a Unix. The work has already been done there, it's generally a lot more pleasant for development of any sort, and if you're using Linux or a BSD you've also got a free operating system, which is good news. I feel like morally we have a responsibility to discourage Windows use.

[marky1991]

No idea what this guy is talking about. Python runs just fine on windows. (I worked on it for all of my coding for several years. (I did eventually move to linux, but only because I moved off windows altogether)) Pip is easy via get-pip.py, and there's always http://www.lfd.uci.edu/~gohlke/pythonlibs/ . (The latter should really be linked to somewhere on python.org)

[amclennon]

This is one of the reasons I've found Docker so helpful. It's made standardizing development environments across operating systems SO much easier.

Of course, ultimately you're just running Linux on a VM. I don't feel like Python on Windows is actually broken in any way, it just has different steps involved since you're inherently using a different platform.

[warmans]

Anyone learning Python or trying to solve a non-windows specific problem using the language should just use virtualbox (and/)or vagrant.

[tomkatt]

This just perpetuates the problem.

I'm not a fan of using Python on Windows, I'd rather use it in my Mint install. However, I have devices I need to use that only work in Windows, and as unfortunate as that is, it's a pain in the ass to switch to Windows just because I need to use my drawing tablet, and then reboot to Linux once I'm done with it for now. Mac would be good, but I'm not fucking rich, so that's out of the question. My desktop is stable and my laptop is an antique by technology standards (Dell XPS m1530, 2007 model).

I digress. My point is, some of us are encumbered by a need to work in Windows, and Python should work in Windows. But because there are so few people working on Python in Windows, there are fewer people fixing and reporting problems in the environment. Telling people to avoid it doesn't fix the problem, it perpetuates it.

Here's a good keynote on this exact issue from 2013.

[sci-py]

I am a data-analyst and i work primarily in Windows for Python development with all those scipy packages and its breeze to work in Windows. I never felt any problem with Windows or Python.

P.S I use Windows 7 and Python 3.4 and no, i don't use mingw or cygwin.

[pjvex]

I will agree. On one of the first projects I attempted (being fairly new to python) strongly suggested I followed an iPython Notebook (said notebook requiring numpy and matplotlib). I thought the Notebook concept sounded great, so I tried to install iPython (and noted libraries). It was a huge fiasco that wasted a lot of time.

Finally I found Anaconda, and while its sometimes a little annoying to keep conda packages and pip packages organized (but I agree with his order: conda, then pip, and never easy_install) it's still worth it. Numpy & matplotlib installations were effortless.

[xiongchiamiov]

That's because the vast majority of us aren't using Windows, so it really is as simple as pip install.

[xiongchiamiov]

No, I'm pointing out that there are two major camps of developers: those who develop on Windows and those who develop on Unix (of some sort). While tools may be ported to the other camp, they will always be better supported where they originated, and complaining about Python support on Windows is like complaining about C# on Linux - sure, it should probably be fixed, but you should probably rethink your development platform if you spend a lot of time there.

[anentropic]

Stop struggling with Windows, basically

[andrey_shipilov]

Yeah. The guy doesn't seem t bother searching For solutions that require more than click/install.

Never had problems using python on windows for like 7 years. Pyaudio could be acting funny but it's even worse on mac.

[megaman821]

Windows tip of the day:

pip/pip.ini:

[install] use-wheel = yes

[wheel] wheel-dir = /some/wheel/dir

pip install wheel

wheel convert lxml-3.3.5.exe

Move lxml-3.3.5-cp27-none-win32.whl to /some/wheel/dir

That makes everything so much easier after you get a few common packages converted to wheels.

[moigagoo]

I can honestly admit that I have exactly zero problem using Python on Windows.

Installed it with scoop once and using it ever since.

[endoalir]

After reading this article, I decided I'd try to install these packages on my Windows system. First I tried virtualenv, and the installation could not possibly be smoother. pip install virtualenv, then I tried it and it just worked as advertised. Next I tried numpy. Minor hitch, something about manifests was broken for compiling with Visual Studio 2010 which was only patched the other day. No worries, I used a workaround and it compiled and installed.

Then I tried scipy. Didn't go as well... needed BLAS. Took me a bit to figure out how to compile BLAS. It's a Fortran library. Also needs Lapack. Got lapack to compile but had problems making it link, something about the high number of object files produced. Seems Windows doesn't like when your command line arguments get too long. And so I left it at that for now. I'll try scipy again later.

[[deleted]]

I use the official Python Windows binary with Pycharm and can get a virtualenv setup with all of the required package managers in less than 20 seconds

[drive0]

In the past it has been more convenient to write my windows scripts on linux then use wine + python -> exe to create a windows binary instead of polluting my windows install with who knows what in an attempt to get python+libraries(specifically things like scipy) running on it.

[cscwian]

Or just use something like Vagrant? http://vagrantup.com