[Python.NET] homebrew pythonnet, versus pip install --pre pythonnet

Wed Jun 4 21:38:18 CEST 2014

Ok, actually we are talking past each other. The problem Adam had apparently
has nothing to do with the migration or the pip stuff, it probably is just
caused by a bug introduced in a recent commit, the code Adam identified. We
should fix that once we have figured out all the details.

As far as I can tell building from VS still works, none of the changes made
should cause a problem for that. If they did, we should fix them, but so far
I am not aware of anything that broke building from VS.

I also want to stress that what we have on github right now is not a
released version. We are slowly working towards a release. If you find bugs
or regressions in the prerelease version, please help us to fix them. The
best way to make sure things work in your environment is to test and help
out.

From: PythonDotNet
[mailto:pythondotnet-bounces+anthoff=berkeley.edu at python.org] On Behalf Of
Bradley Friedman
Sent: Wednesday, June 4, 2014 11:36 AM
To: pythondotnet at python.org
Subject: Re: [Python.NET] homebrew pythonnet, versus pip install --pre
pythonnet

Yes.  But the problem is: before the migration, those things DID work.  And
it was the pip/setup.py that needed to be fixed up.  It sounds like you're
saying you've sacrificed all of it just to get a pip install working for
windows.  This is extremely troubling.  I have not looked at the git branch
yet.  But now I need to investigate what exactly is going on.

On Jun 4, 2014, at 1:46 PM, David Anthoff <anthoff at berkeley.edu
<mailto:anthoff at berkeley.edu> > wrote:

Pull requests to fix this are more than welcome :) I agree that building
from the IDE should also work, but right now there doesn't seem to be the
man power to fix all of these things.

From: PythonDotNet
[mailto:pythondotnet-bounces+anthoff=berkeley.edu at python.org] On Behalf Of
Brad Friedman
Sent: Wednesday, June 4, 2014 9:49 AM
To: A list for users and developers of Python for .NET
Subject: Re: [Python.NET <http://Python.NET> ] homebrew pythonnet, versus
pip install --pre pythonnet

Umm. As an asside:  seriously?  You are only supporting setup.py builds from
this branch?  That's a problem.  <http://python.net/> Python.net is also
used to embed python. Therefore, it should build from IDE on all platforms
and also from an autotools system. 

On Jun 4, 2014, at 6:15 AM, Tony Roberts < <mailto:tony at pyxll.com>
tony at pyxll.com> wrote:

Hi Adam,

that 2.0.0.beta1 build was built from the source on github here:

 <https://github.com/pythonnet/pythonnet>
https://github.com/pythonnet/pythonnet

You should build it using the setup.py script and not in the IDE.

There are CI builds setup for both windows and linux (see README.md) if you
want to see exactly how the wheel gets built.

Best regards,

Tony

On Wed, Jun 4, 2014 at 3:48 AM, Bradley Friedman < <mailto:brad at fie.us>
brad at fie.us> wrote:

Can you provide the contents of the ".Config" file that is built with your
particular build solution?  There's a pretty good chance that the
"FileNotFound" is actually mono trying to link back to Python shared
libraries.  Though to be honest, debugging is going to be your best bet
here.  You might try building in Xamarin or MonoDevelop on the mac, to be
able to debug more easily.

-brad

On Jun 3, 2014, at 7:15 PM, Tribble, Brett < <mailto:btribble at ea.com>
btribble at ea.com> wrote:

It has been a while since I've had to deal with this, but make sure that
your assembly is in the system path and/or pythonpath if it is not
registered in the GAC.

From: PythonDotNet [
<mailto:pythondotnet-bounces+btribble=ea.com at python.org>
mailto:pythondotnet-bounces+btribble=ea.com at python.org] On Behalf Of Adam
Klein
Sent: Tuesday, June 03, 2014 4:02 PM
To:  <mailto:pythondotnet at python.org> pythondotnet at python.org
Subject: [ <http://python.net/> Python.NET] homebrew pythonnet, versus pip
install --pre pythonnet

Hi All,

Amazing library, first of all!

I am experimenting with integrating ipython / numpy / pandas for interactive
data analysis with our large existing C# codebase. We are using the Anaconda
2.0 release from ContinuumIO. With `pip install -pre pythonnet`, everything
goes as expected (great!)

However, when I build from source (in VS2013), point my PYTHONPATH to the
clr.pyd and Python.Runtime.dll that results from the build, and run my
ipython, I can do `import clr` and `ref = clr.AddReference("assemblyname")`,
but I cannot load any modules within this assembly. I get a `ImportError: No
module named .` Furthermore, if I try to do ref.ExportedTypes, I get a
`FileNotFoundException: Could not load file or assembly .` where it cannot
find an assembly that is referenced by the original assembly. There must be
some broken loading going on. Any thoughts why this might have different
behavior than what I install via PyPI (
<https://pypi.python.org/pypi/pythonnet/2.0.0.dev1>
https://pypi.python.org/pypi/pythonnet/2.0.0.dev1)? Or, hints on how to
debug?

Thanks!!!

--Adam

  _____  

This e-mail is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any
action in reliance upon, the information in this e-mail by persons or
entities other than the intended recipient is prohibited and may be
unlawful. If you received this in error, please contact the sender and
delete the material from any computer.

This communication is for informational purposes only. It is not intended as
and does not constitute an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any transaction.
All market prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice. Any
expected returns are provided for illustrative purposes only and are not
intended to serve as, and must not be relied upon by any prospective
investor as, a guaranty, an assurance, a prediction of a definitive
statement of fact or a probability. Investment in funds managed by
BlueMountain carries certain risks, including the risk of loss of principal.
Unless indicated otherwise, performance results are presented net of fees
and expenses. Certain market and economic events having an impact on
performance may not repeat themselves. Any comments or statements made
herein do not necessarily reflect those of BlueMountain Capital Management,
LLC or its affiliates. PAST PERFORMANCE IS NOT NECESSARILY INDICATIVE OF
FUTURE RESULTS AND NO REPRESENTATION IS MADE THAT RESULTS SIMILAR TO THOSE
SHOWN CAN BE ACHIEVED.

_________________________________________________
 <http://python.net/> Python.NET mailing list -
<mailto:PythonDotNet at python.org> PythonDotNet at python.org
 <https://mail.python.org/mailman/listinfo/pythondotnet>
https://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
 <http://python.net/> Python.NET mailing list -
<mailto:PythonDotNet at python.org> PythonDotNet at python.org
 <https://mail.python.org/mailman/listinfo/pythondotnet>
https://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
 <http://python.net/> Python.NET mailing list -
<mailto:PythonDotNet at python.org> PythonDotNet at python.org
 <https://mail.python.org/mailman/listinfo/pythondotnet>
https://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
 <http://python.net/> Python.NET mailing list -
<mailto:PythonDotNet at python.org> PythonDotNet at python.org
 <https://mail.python.org/mailman/listinfo/pythondotnet>
https://mail.python.org/mailman/listinfo/pythondotnet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythondotnet/attachments/20140604/640de46c/attachment-0001.html>