Fix build issues

[jseabold]

Closes #204. Tested under linux with bleeding edge. Tested both source installation and binary installation on Windows with minimum packages for Python 2.6, 2.7, and 3.2 32- and 64-bit. There is one problem with 2to3 on 32-bit only. For some reason it doesn't change from linbin import fast_linbin to a relative import. It does change the kalman filter one, so I don't think it has anything to do with the extension. Will have to check later. Changing this after it's installed, it tests fine.

There are some failing tests on Windows (probably versions dependent), but that's a different PR.

[rgommers]

works for me

[jseabold]

Thanks, Ralf. Is that on OS X?

45facae should fix the relative imports issue. I will test the windows binary build tonight to be sure.

[rgommers]

Nope, moved to Linux. 32-bit Ubuntu

[jseabold]

Windows binaries are up for testing. It is literally two lines of code to build and upload them to sourceforge at whatever frequency we want using the Windows Task Scheduler. I just don't have a machine that's always on with windows installed.

http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.win-amd64-py2.6.exe
http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.win-amd64-py2.7.exe
http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.win-amd64-py3.2.exe
http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.win32-py2.6.exe
http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.win32-py2.7.exe
http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.win32-py3.2.exe

[jseabold]

Source distributions are up too from the same build script. I haven't checked them yet though.

http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.tar.gz
http://statsmodels.sourceforge.net/binaries/statsmodels-0.5.0-dev.zip

[jseabold]

We need a windows machine with an SSH key for the sourceforge site. The SSH key should have no password.

Install the SDK as described here

Download pscp and put it in C:\windows\

Update the statsmodels\tools*.bat files to point to the correct path for Python installations.

The batch file that task scheduler would have to run is

call C:\path\to\statsmodels\build_bdists.bat
pscp.exe C:\path\to\statsmodels\dist\* username,statsmodels@web.sourceforge.net:htdocs/binaries/

I can set this up on my laptop, but I only boot up windows when I need to do my taxes or build statsmodels for a release, so they would be updated infrequently.

[rgommers]

nice. shouldn't those binaries have -dev in the name? Looks like an official release now.

[jseabold]

Yeah, I didn't mess with the release numbering. Just wanted to see that they worked. I'll change.

[jseabold]

Updated the links.

[jseabold]

I scraped together my change and built a windows build slave, so we should have nightly binaries now once all the kinks are worked out. Looks like Python 3.3 might have had some build problems, but I haven't tested it yet.

https://github.com/statsmodels/binary_builds

They will be here nightly (if there have been commits in master).

http://statsmodels.sourceforge.net/binaries/

Would like to also get the python 2to3 caching that pandas has but that will have to wait.

@josef-pkt I added you to the upload e-mails, but they're not like the docs upload e-mails in that they don't give any indication of if / where things went wrong. Let me know if you want me to take you off this.

[jseabold]

I removed the 3.3 binaries until I fix the builds.

[josef-pkt]

Being on the upload emails is fine.

what's python 2to3 caching? I assume we switch to a common py >2.6 > 3.1 code base soon (following scipy and numpy), So if this sounds like too much work, I would skip it because once we switch, 2to3 won't be necessary anymore.

What's the problem with python 3.3?

[jseabold]

That's fine then caching won't matter.

I can't tell yet what's wrong with 3.3. It looks similar to the relative import problem, but that's fixed in 3.2, and this one is with kalman_loglike not linbin.

[josef-pkt]

Is it with 2to3 conversion? If you make changes in the converted py 3.3 code, can you build it?

[jseabold]

No it's a linking error I think. I just don't think you can use this version of the SDK for 3.3. I'll need to look into it.

[jseabold]

Yeah you need Windows 7 and .NET SDK Framework 4 for 3.3. Version 3.5 SP1 works for 2.6 - 3.2. I just need to install it and a couple of lines in the batch files.

[jseabold]

Everything should be fine now.

[jseabold]

Can I merge this?

[jseabold]

Bump.

[josef-pkt]

I will try it out tonight.

I liked the decentralized numpy distutils version better, but so far I didn't have problems compiling pandas with MingW for 32bit, so this might be fine.

Especially your work providing nightly (or at least updated) binaries sounds good.

(The main difference for me will be that I need python specific inplace builds, instead of just running from source with any python 2.)

[jseabold]

Ok, thanks. I liked the modular version too given that we don't keep the source together in a folder. We might be able to work back to that. It was just easier for me to crib this version, though now I have a decent idea of how it all works.

I added some instructions on automating the builds on windows to docs for easy batch scripting that should help. I have bash scripts for all the projects I build from source regularly.

[jseabold]

Any luck? Hoping to get a release candidate out this week.

[jseabold]

I would like to merge this this weekend, so I can point the build box at master and put it away.

[josef-pkt]

Go ahead and merge. (I'll figure it out ex-post.)

Try to have a clean merge, so I can possible create a branch where I can revert this.

(I still don't manage to get back to maintenance. I'm still busy with GSOC related things. But I would like to merge my misc07 before a release candidate.)