Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Windows? #32

Closed
DirectXMan12 opened this issue Dec 23, 2014 · 19 comments
Closed

Support Windows? #32

DirectXMan12 opened this issue Dec 23, 2014 · 19 comments

Comments

@DirectXMan12
Copy link
Member

We may wish to consider supporting Windows at some point

@filmor
Copy link
Contributor

filmor commented Jun 19, 2015

What needs to be done to get there?

@DirectXMan12
Copy link
Member Author

  1. Compilation needs to be tested in Windows with MIT Kerberos for Windows on MinGW.
  2. The conditional compilation logic needs to be adjusted to work for Windows
  3. We need a way to build wheel files for Windows (optional, but useful for anyone who actually wants to use this on Windows).

@frozencemetery
Copy link
Member

Other "nice to have" - some way to run our test suite, since I don't think k5test will work there.

@ibigpapa
Copy link

So using the MIT KfW. I see the source is available as well as precompiled sources could we just wrap these to make it work?

@DirectXMan12
Copy link
Member Author

DirectXMan12 commented Sep 14, 2016

yeah, it really comes down to finding time and a Windows box to test on (plus setting up CI to make sure we don't break anything), plus tweaking setup.py to work properly on Windows.

@ibigpapa
Copy link

I'm working on trying to hack this in myself let you know how i do.

@DirectXMan12
Copy link
Member Author

cool. Feel free to ping us on #python-gssapi on freenode if you have any questions best answered in a real-time manner (I'm usually on from 10:00-17:00EST)

@frozencemetery
Copy link
Member

2a2b47b adds support for conditional compilation. Still missing are building wheels and running buildjob CI. Much like with Heimdal, a stretch goal is to port k5test so we can run the test suite there.

@aiudirog
Copy link
Member

aiudirog commented Jun 8, 2019

I've been working on Windows support the past couple of days to get my company to move off of requests-kerberos (I had previously patched ccs-kerberos to work on Windows) and got everything to compile properly under VS Build Tools, MinGW, and MSYS. Unfortunately I won't be able to test until I'm back at work on Monday since k5test isn't ported yet. My current progress can be found here.

Changes:

  • I created a predefined macro (__MSYS__) to allow the header files to detect MinGW under MSYS so that when it isn't under it, they can target MIT Kerberos for Windows instead (which also seems to have better extension support).
  • To get it compile under VS:
    • I had to cast all slicing of gss_buffer_desc.values to char* because many platforms seem to declare it as a void* instead and cl.exe doesn't like void* pointer arithmetic. This can be found a separate commit.
    • libraries is now passed separately to Extension like library_dirs so that Extension itself can determine how to pass them to the linker.
  • link_args and compile_args are now always lists. This is to support arguments which may have spaces in them, like include paths on Windows.

@aiudirog
Copy link
Member

Everything seems to be working as expected. I was able to connect to our internal Apache Livy and Phoenix servers on Windows and use them as normal through requests-gssapi.

@frozencemetery
Copy link
Member

That's awesome, well done! Do you have any idea how this could be tested in CI? (Presumably just checking that the build works, as we do with Heimdal, since the krb5 server parts don't run on Windows, but don't let me stop you if you're feeling ambitious.)

@aiudirog
Copy link
Member

I've been looking into it and Travis does support Windows now so I'll put some work into at the very least getting it to build and generate wheels.

@aiudirog
Copy link
Member

I've opened a pull request to start playing with the Travis build. Hopefully this goes more smoothly than I'm expecting.

@aiudirog
Copy link
Member

@frozencemetery I have it building on 2.7, 3.6, and 3.7 on Windows and I think I configured the deployment right, though I'm not sure. This is my first time using Travis (only experience with Jenkins, though I'm liking Travis a lot) so I might have missed something. Is there any way to do a mock deployment to test it?

@frozencemetery
Copy link
Member

Either you figured it out, or I'm not understanding the question :) Please post a comment in that PR when it's ready for review.

@aiudirog
Copy link
Member

My question was purely about deploying the wheels. Not sure if I set it up right since you can't test deployment from a PR. I guess we can test once it's merged.

@frozencemetery
Copy link
Member

@aiudirog So I ran into some problems trying to cut a release for this. I made some fixes - a6e3f08 and 5c80107 - but then I ran into failure trying to use pypi - first second and third subjobs.

It seems to me - and please let me know if this isn't right - that we can't build wheels from Travis right now. That being the case, how would you feel about using Appveyor for this instead? (I think that works...)

@neirbowj
Copy link
Contributor

I just have to say---and I know that this isn't necessarily appropriate for an issue thread---that I really appreciate the work each of you is doing to help achieve this. I wish there were more I could do to help move things along.

@aiudirog
Copy link
Member

aiudirog commented Jul 17, 2019

This seems to be the issue to keep an eye on.

For now, we can probably just manually upload using a script deployment and twine. I'm going to give that a try before redoing the whole thing in Appveyor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants