Why is Python for Windows compiled with MSVC?
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?
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 registered 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.
On Wed, Jan 31, 2018 at 3:04 PM, Oleg Sivokon olegs@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 regi 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
On 2018-01-31 19:07, Ray Donnelly wrote:
On Wed, Jan 31, 2018 at 3:04 PM, Oleg Sivokon olegs@traiana.com wrote:
Hello list.
I'll give some background before asking my question in more detail.
[snip]
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). I build the wheels (binaries for Windows) for the regex module using
mingw-w64 and they also work just fine.
I can also build using Microsoft Visual Studio Community 2017 (which is free) and they work.
[snip]
On 1/31/2018 10:04 AM, Oleg Sivokon wrote:
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
Python was ported to DOS years before the initial 1998 release of the mingw32 predecessor. There has been some work to make Python also compile with MinGW, but AFAIK, no one has volunteered to persist in doing complete patch for MinGW. You can look at the tracker to get some idea of what is missing. I presume contributions are still allowed and welcome.
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?
Timely access to all features added to Windows, such as 64 bit binaries. Access to everything compiled with the compiler nearly everyone else uses. Help to make Python work on DOS, now Windows, from people who only know and use Microsoft tools.
communication and all information contained in or attached to it isconfidential, intended solely for the addressee,
Please omit this noise. Posting to pydev is posting to the world, including multiple mirrors and repositories.
Because every other supported platform builds using the native tools, so why shouldn’t the one with the most users?
I’m likely biased because I work there and I’m the main intermediary with python-dev, but these days Microsoft is one of the strongest supporters of CPython. We employ the most core developers of any private company and we all are allowed work time to contribute, we provide full access to our development tools and platforms to all core developers and some prominent projects, we’ve made fixes, enhancements and releases or core products such as the CRT, MSVC, Visual Studio, Visual Studio Code, and Azure SPECIFICALLY to support CPython development and users. As far as I know, ALL the Windows buildbots are running on Azure subscriptions that Microsoft provides (though managed by some awesome volunteers). You’ll see us at PyCon US under the biggest banner and we’ll have a booth filled with engineers and not recruiters. Crash reports from thousands of opted-in users come into our systems and have directly lead to both CPython and Windows bug fixes.
Meanwhile, most of the MinGW contributions have been complaints and drive-by patches. We (python-dev) are not opposed to supporting a second compiler for Windows, and honestly I’d love for extensions built with other compilers to be fully compatible with our main binary release, but the sacrifice involved in switching is significant and there’s no apparent commitment from the alternative options.
(Note that I’m not saying Microsoft’s support is conditional on our compiler being used. But our ability to contribute technically would be greatly reduced if we didn’t have the inside access that we do.)
And as has been mentioned, MSVC was selected before the other options were feasible. Python is a much older tool than those others, and so uses the tools that were best at the time.
So in my opinion at least, the reasoning for selecting MSVC was perfectly sound, and the reasoning for continuing with it is perfectly sound. Unwillingness on the part of package developers to not even test on Windows before releasing a wheel for it is not a compelling reason to change anything.
Cheers, Steve
Top-posted from my Windows phone
From: Oleg Sivokon Sent: Thursday, February 1, 2018 5:40 To: python-dev@python.org Subject: [Python-Dev] Why is Python for Windows compiled with MSVC?
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?
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 regi 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/steve.dower%40python.org
participants (6)
-
MRAB -
Oleg Sivokon -
Ray Donnelly -
Steve Dower -
Steven D'Aprano -
Terry Reedy