Provide wheels for Python 3.5 on Windows about swiglpk HOT 12 CLOSED

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.

from swiglpk.

@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

from swiglpk.

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

from swiglpk.

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.

from swiglpk.

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.

from swiglpk.

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).

from swiglpk.

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

from swiglpk.

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.

from swiglpk.

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)

from swiglpk.

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...

from swiglpk.

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 *.

from swiglpk.

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 :)

from swiglpk.