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" <davidacoder@hotmail.com> wrote:

Hi,

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 pypi.python.org 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?).

Thoughts?

Thanks,

David

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org https://mail.python.org/mailman/listinfo/pythondotnet

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. -brad On Nov 28, 2013, at 12:33 PM, Barton <barton@bcdesignswell.com> 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" <davidacoder@hotmail.com> wrote: Hi,

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 pypi.python.org 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?).

Thoughts?

Thanks,

David

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org https://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org https://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org https://mail.python.org/mailman/listinfo/pythondotnet

On Thu, Nov 28, 2013 at 1:17 PM, davidacoder <davidacoder@hotmail.com>wrote:

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.

The .NET Client Profile is installed by default, but not the full framework nor the developer tools. In fact, most of the python developers I know do not have the .NET development tools installed. Being forced to install them would be a barrier to entry for them. The users of their apps definitely don't have the compiler installed, nor should they have to.