-
Notifications
You must be signed in to change notification settings - Fork 751
Rebased #154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebased #154
Conversation
from sdpython/pythonnet3
refactored all logical changes from just appending python3.5 to everything
@@ -3,9 +3,9 @@ pythonnet | |||
|
|||
Python for .NET is a package that gives Python programmers nearly seamless integration with the .NET Common Language Runtime (CLR) and provides a powerful application scripting tool for .NET developers. It allows Python code to interact with the CLR, and may also be used to embed Python into a .NET application. | |||
|
|||
[](https://travis-ci.org/pythonnet/pythonnet) | |||
[](https://travis-ci.org/denfromufa/pythonnet) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting branch to develop
might make sense, but if you're pushing to the main repo you should keep the reference as it is ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I think we should merge into master and do a 2.1 release as soon as
the 3.5 stuff is all working and tested, so the CI build statuses should be
left as they were.
On Mon, Feb 22, 2016 at 10:43 AM Benedikt Reinartz [email protected]
wrote:
In README.md
#154 (comment):@@ -3,9 +3,9 @@ pythonnet
Python for .NET is a package that gives Python programmers nearly seamless integration with the .NET Common Language Runtime (CLR) and provides a powerful application scripting tool for .NET developers. It allows Python code to interact with the CLR, and may also be used to embed Python into a .NET application.
Setting branch to develop might make sense, but if you're pushing to the
main repo you should keep the reference as it is ...—
Reply to this email directly or view it on GitHub
https://github.com/pythonnet/pythonnet/pull/154/files#r53608999.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tonyroberts you can see on my branch that py35 is working and tested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When this is merged the same will hold for the original links :)
@denfromufa there are too many closely related commits that haven't been squashed, and a lot of commits with no meaningful commit message. I am also suspicious of the test that you have commented out, but I have not had time yet to check whether it was a valid test or not. |
As I see it, there should be at most 4 commits.
Everything else will drop out once this is rebased correctly. |
@@ -40,6 +40,18 @@ def _find_msbuild_tool(tool="msbuild.exe", use_windows_sdk=False): | |||
locappdir, vcpy27, r"x64\mt.exe") | |||
if os.path.exists(mtpath): | |||
return mtpath | |||
if sys.version_info[:2] == (3,5): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There shouldn't be any need for hardcoded paths. Not everyone will have installed the windows SDK on the C drive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tonyroberts I agree, but I did not find in registry this path. also not sure if windows sdk can be installed to non-default paths?! maybe @zooba can point how this path can be mapped in more generalized way? (r"C:\Program Files (x86)\Windows Kits\8.1\bin")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removing from rebase. agree with @tonyroberts
@denfromufa may need to add it to the registry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots
is where you'll find the install directories of the Windows dev kits. (In 64-bit processes on 64-bit systems it'll be HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows Kits\Installed Roots
- easiest to try the other one first and then fall back to the longer path.)
@tonyroberts @vmuriart @filmor I'm quite busy with my day job until end of this week. if anyone wants to rebase properly or get a clean fork, please go ahead before that, even if it does not include my commits. I also like @tonyroberts idea testing with debug build of CPython, especially since you can step through C#/C/Python code in PTVS if debugging is needed! |
@denfromufa @tonyroberts I went ahead and cleaned up the git commits and squashed them into more unit like commits on my fork. I hate to have to close this PR to open a new one again... Selavi. @tonyroberts i consolidated some of the strange changes of code (moving the comments you mention, some debug statements). I tried troubleshooting that commented out test as well but haven't been able to get it passing. The error that we get is the same one that was pointed out in the comment; it fails with |
pr #160 is cleaned up and addresses the comments above. |
rebased from #153