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
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
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 setup.py 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 setupwin.py already, so I guess it would be a matter of integrating that stuff into the default setup.py, 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? Cheers, David From: PythonDotNet [mailto:pythondotnet-bounces+davidacoder=hotmail.com@python.org] On Behalf Of Bradley Friedman Sent: Thursday, November 28, 2013 12:01 PM To: pythondotnet@python.org 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. -brad On Nov 28, 2013, at 12:33 PM, Barton <barton@bcdesignswell.com <mailto: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 <mailto: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 <http://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 <http://Python.NET> mailing list - PythonDotNet@python.org <mailto:PythonDotNet@python.org> https://mail.python.org/mailman/listinfo/pythondotnet _________________________________________________ Python.NET <http://Python.NET> mailing list - PythonDotNet@python.org <mailto:PythonDotNet@python.org> https://mail.python.org/mailman/listinfo/pythondotnet _________________________________________________ Python.NET <http://Python.NET> mailing list - PythonDotNet@python.org <mailto: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.
You are right, I had forgotten about that. I think the Client Profile is discontinued starting with .Net 4.5, but given that Python.NET should work with older versions as well, that doesn't really help. Well, I guess that does mean that wheels would be nice. Either way, the first step will be to create a working setup.py for both windows/linux/mac. Cheers, David From: PythonDotNet [mailto:pythondotnet-bounces+davidacoder=hotmail.com@python.org] On Behalf Of Zane D. Purvis Sent: Friday, November 29, 2013 1:29 PM To: A list for users and developers of Python for .NET Subject: Re: [Python.NET] pip and wheel On Thu, Nov 28, 2013 at 1:17 PM, davidacoder <davidacoder@hotmail.com <mailto: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.
participants (5)
-
Barton -
Bradley Friedman -
davidacoder -
Kyle Rocha -
Zane D. Purvis