On Wed, Jan 31, 2018 at 3:04 PM, Oleg Sivokon <ol...@traiana.com> wrote: > Hello list. > > I'll give some background before asking my question in more detail. > > I've been tasked with writing some infrastructure code that needs to talk to > Kubernetes. (Kubernetes is a popular software for managing and automating > virtualization / containerization of cloud services). One of the > requirements was that the code be written in Python 3.X. > > The tasks my code was supposed to perform on Kubernetes would be something > like cluster creation from specification, deletion of all or parts of the > cluster, providing realtime statistics of cluster usage etc. There were few > prototype scripts written in Bash using kubectl (official client written in > Go). > > My first reaction was to look for an official client for Kubernetes written > in Python. There is one official client for Kubernetes, with a single > maintainer, impossible to parse documentation, containing mostly generated > code. It is nigh impossible to use. Here I need to explain that for > whatever reason Kubernetes team decided to write their HTTP API in such a way > that the server is "dumb" and the client must be "smart" in order to do > anything useful. For instance, if you have a description of your cluster, > you cannot just send this description to the server and hope that it will > know how to create the cluster from description. You need to make multiple > API calls (perhaps hundreds of them) to arrange for the server to create the > cluster from description. > > Since the official client is no help (it really only mirrors the HTTP API), I > searched for other clients. There are two more. None is in good shape, and > none comes even close to being able to do what kubectl can. > > There is one more client that shells out calls to kubectl. It implements > only a small subset of kubectl commands, and... it's a lot of parsing of > standard output with regular expressions and magic. > > Well... I was given a lot of time to investigate other options for dealing > with this project, so I decided, what if I can compile kubectl into a shared > library and write a Python extension that links against that library. And, > indeed, after few days I came up with such an extension. It worked!.. On > Linux... > > Now all I had to do was to re-create my success on Windows (most of the > employees in my company use Windows). At first I thought that I'd > cross-compile on Linux using MinGW. I compiled Go shared library into a DLL, > then tried to compile my Python extension and... it didn't work. I > downloaded VirtualBox and some Windows images, etc... tried to compile on > Windows. It didn't work. I started asking around, and was told that even > though for some earlier versions of Python this was kind of possible, for > Python 3.5, 3.6 it is not. You must use MSVC to compile Python extensions. > No way around it. > Now, since Go won't compile with MSVC, I'll have to scrap my project and > spend many weeks re-implementing kubectl. > > Here's my question: Why? > > Why did you choose to use non-free compiler, which also makes > cross-compilation impossible? There wasn't really a reason not to choose > MinGW as a way to compile extensions on Windows (Ruby does that, Go uses > MinGW, perhaps some others too). It would've made things like CI and > packaging so much easier... What do Python users / developers get from using > MSVC instead?
You can compile extension modules with mingw-w64 just fine (modulus a few gotchas). The Anaconda Distribution we do this for a few packages, for example rpy2. You can see the build script used here: https://github.com/AnacondaRecipes/rpy2-feedstock/blob/master/recipe/bld.bat (disclaimer: I work for Anaconda Inc on this stuff). MSYS2 also have mingw-w64 builds of Python that might meet your needs. It is pretty popular in some parts of the open source on Windows world (disclaimer: I did a lot of the work for this stuff on MSYS2). > > Thank you. > > Oleg > This communication and all information contained in or attached to it is > confidential, intended solely for the addressee, may be legally privileged > and is the intellectual property of one of the companies of NEX Group plc > ("NEX") or third parties. If you are not the intended addressee or receive > this message in error, please immediately delete all copies of it and notify > the sender. We have taken precautions to minimise the risk of transmitting > software viruses, but we advise you to carry out your own virus checks on any > attachments. We do not accept liability for any loss or damage caused by > software viruses. NEX reserves the right to monitor all communications. We do > not accept any legal responsibility for the content of communications, and no > communication shall be considered legally binding. Furthermore, if the > content of this communication is personal or unconnected with our business, > we accept no liability or responsibility for it. NEX Group plc is a public > limited company re gi > stered in England and Wales under number 10013770 and certain of its > affiliates are authorised and regulated by regulatory authorities. For > further regulatory information please see www.NEX.com. > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/mingw.android%40gmail.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
