That is great news.


I originally suggested that a binary wheel upload to pypi might be good, but thinking about that I’m actually not so sure anymore that that is needed. Maybe just a source release with a working would do? After all, on windows msbuild and the c# compiler are installed by default on pretty much any machine in any case, compile times shouldn’t be much of a problem, and so if my understanding of pip is correct, we could have full pip support with a source release on pypi.


I actually also saw that Tony’s fork had a already, so I guess it would be a matter of integrating that stuff into the default, making sure that it works on windows/linux/osx and clr/mono, and that should get us pretty close to getting “pip install pythonnet” work, right?





From: PythonDotNet [] On Behalf Of Bradley Friedman
Sent: Thursday, November 28, 2013 12:01 PM
Subject: Re: [Python.NET] pip and wheel


And have worked for me with mono on OSX both under mono-develop and also via make.  Both with precompiled 32-bit mono and also custom compiled 64-bit mono.  With some hammering.  If we made an effort to get it set right for pypi, I'd think it would be worth getting that build support settled once and for all as well.




On Nov 28, 2013, at 12:33 PM, Barton <> wrote:

On point #1:
Yes, both package management and the unmanaged exports package work correctly on linux under MD.

On 11/27/2013 1:38 AM, Kyle Rocha wrote:

I would like to continue to see proper mono support available.

That does lead me to some questions about that unmanaged exports package.
1. Does that stuff work correctly when you're using something like monodevelop?

2. Why was the change made to use that over the manually written clr bindings? Was it only to simplify the binding process?

/ Kyle

On Nov 26, 2013 9:18 AM, "davidacoder" <> wrote:



I think one major barrier for easier adoption of pythondotnet right now is setup, i.e. how you get to a point where you can just use it.


I think there are a couple of issues:


- the download page on sourceforge is confusing. There are five folders on the first page that don’t seem to follow some common naming scheme. Three have a pythonnet version in it, one doesn’t have any version in the name and the last one refers to a CLR version. If I land there I just don’t know what to do next.

- There doesn’t seem to be a win x64 download, which I would assume to be the major version in use right now.

- In general the builds seem to be old

- There don’t seem to be mono builds (although, should there be?)


At the same time I feel that with the new package stuff happening in the general python world the idea of having a binary zip file download is getting old in any case.


One potentially elegant way around this is to provide binary wheels for pythondotnet that are hosted on for windows. I don’t know how the mono stuff would work and multi-platform things, though… In any case, I think it should be feasible at that point to simply use pip to install pythondotnet:


pip install pythondotnet


and that would do the trick. And now that pip is bundled in the default python distribution, I feel that would essentially solve the distribution problem completely, right? I think such a pip install should just make the clr module available for import. I am less sure whether such a wheel install should also put npython.exe somewhere onto the path (scripts folder?).








Python.NET mailing list -

Python.NET mailing list -


Python.NET mailing list -