Provide wheels for Python 3.5 on Windows

Question

Provide wheels for Python 3.5 on Windows

cdiener opened this issue 8 years ago · 12 comments

Just adding the required entries to the build matrix should fix this.

Answer 1 · 2016-11-23T18:41:15.000Z

@cdiener any clue why it is so hard to add 3.5 to the build matrix? The error is really bizarre. Test runs fine actually. https://ci.appveyor.com/project/phantomas1234/swiglpk/build/job/eyllplsdg5i53rrn

Answer 2 · 2016-11-23T19:09:02.000Z

Probably some problems with some linker flags. But laready saw that you are trying with ogrisel's build. That should work...

Answer 3 · 2016-11-23T19:30:48.000Z

Hmm does not seem to resolve the problem. The linker problem could also be due to the glpk.lib having been compiled with an older Visual Studio. Maybe you will also need to recompile glpk itself.

Answer 4 · 2016-11-23T19:33:35.000Z

Unfortunately not https://ci.appveyor.com/project/phantomas1234/swiglpk/build/job/nmdjbdfgvturx8r2. I'd say it is probably due to glpk.lib. No clue how to compile glpk on appveyor.

Edit:
I guess conda could be an option.

Answer 5 · 2016-11-23T19:36:58.000Z

In the cobrapy appveyor folder there is a build_glpk.py that downloads, compiles and copies glpk.h and glpk.lib to you project directory. You could try running that one before and see whether that fixes the problems (it should since the cglpk bindings did compile fine for python 3.5).

Answer 6 · 2016-11-23T20:07:27.000Z

If you want rather return swiglpk to its previous state and we'll play around in a new branch.

Some remarks:

The 1.3.1 versions also give me import errors in all other builds.
I think for python 3.5 Ali added the glpk.libUCRT so that should work with the old setup, however I would prefer the build_glpk.py pipeline which should be future-proof

Answer 7 · 2016-11-24T09:59:28.000Z

There was a bug that caused the extension to not be included in the wheels (I missed to add the CustomBuild command to setup); the tests should really run on the wheel to avoid issues like that again. I'd rather not return to the original state because the whole refactoring is just due to this matthew-brett/delocate#12 unfortunately, it seems like it didn't help.

Answer 8 · 2016-11-24T12:31:50.000Z

Ok, I think I finally managed to get this to work https://travis-ci.org/biosustain/swiglpk/builds/178574134 (I am pretty sure the tests are run now using the generated wheels)

Answer 9 · 2016-11-24T12:35:54.000Z

Those are the fixes for manylinux right? Nice! I also send a PR with some shorter appveyor config based on the Python packaging guide, but we might also want to run the tests on the wheel there too...

Answer 10 · 2016-11-24T14:43:22.000Z

mac wheels still seem to be broken (though tests on travis pass). If I install from this prerelease https://pypi.python.org/pypi?:action=display&name=swiglpk&version=1.3.2rc1 python -c "import swiglpk; print(swiglpk.glp_version())" still doesn't work. It is a weird import issue though because python -c "import swiglpk.swiglpk as swiglpk; print(swiglpk.glp_version())" works 🤕 This is over my head because it is just a package with swiglpk/__init__.py that just contains from swiglpk import *.

Answer 11 · 2016-11-24T19:19:09.000Z

1.3.3rc1 works fine for me. Seems like you figured it out. I didn't mean to trigger that kind of work, sorry. But thumbs up for all the black magic in order to make it work in the end :)

Answer 12 · 2016-11-24T20:52:40.000Z

Don't worry, this was really overdue and I am glad we have functioning wheels now. Someone else pinged me about this via Email a couple of days go so I thought it would be good to get it done. Thanks with the glpk_build.py tip, that was really helpful. Talk to you soon.