-
Notifications
You must be signed in to change notification settings - Fork 636
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
Switch to use sync version of CPython setup/installation method #11428
Conversation
Task.Run(() => { | ||
Python.Included.Installer.SetupPython().Wait(); | ||
isPythonInstalled = true; | ||
}).Wait(); |
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.
Hey Aaron. I must admit when I heard about the hang I remember I also happened to experience it. Back then, what I did to get rid of it is to make SetupPython
fully synchronous, which is actually a simple change in our Python.Included
fork https://git.autodesk.com/Dynamo/pythonnet/pull/14/files#diff-4cc075ba367f8ff85f7aff06fd5c060aR30. That change didn't make it into master because it was part of the draft for Python module installation support, which is still a RFC.
IMO, making SetupPython
synchronous is a simpler solution. Besides, since the unzip action is almost instantaneous and runs only once it doesn't make much sense for it to be async. That would mean that we would just call Python.Included.Installer.SetupPython();
here.
An alternative, if we don't want to change the existing SetupPython
function, could be to create a synchronous variation named SetupPythonSync
that basically uses the same code I linked.
What do you think about this @QilongTang @mjkkirschner ?
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.
I like adding the new method!
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.
what do you guys think about actually wrapping pythonIncluded in our own namespace? I guess I am concerned that if we need custom functionality that and if a regular build of Python.Included
were loaded into Revit's process by another addin (pyrevit) we would hit a missing method exception.
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.
I guess we could do that but not sure if now is a good time, given it would represent a breaking change. Python .NET could also potentially present clashes. Not sure if we have tested Revit + pyRevit + Dynamo, but we should probably do it to have an idea of how urgent this change should be. What do you think @mjkkirschner ?
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.
@mmisol I'm fine waiting as well and we can discuss those changes together instead - but I am curious - in what sense is it a breaking change?
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.
@mmisol I'm fine with that, I will make that change in this PR soon
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.
Hi @mmisol You just reminded me, we tried that yesterday and found we need to wait for the unzip to finish before executing the graph. If we just call Python.Included.Installer.SetupPython();
the install code in our PythonNet is async so user will get this error
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.
@mjkkirschner Changing the namespace of a public class is technically a breaking change. Probably no-one is using it directly except us, so it could be low risk.
@QilongTang We don't just need a change in Dynamo, but we also need to change Python.Included. If you check the link I shared earlier you'll see the SetupPython
function was changed to being synchronous, though It's probably best if we add a new one named SetupPythonSync
and leave SetupPython
unchanged.
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.
@mmisol Cool. Go ahead for that
This also needs to consume the new binary right? (I think manually copy to extern) |
@QilongTang Could you search for |
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.
Looks good to me. Thanks!
* Use task run to wrap the installation body * Update to use sync version of API * Additional place to fix
…) (#11435) * Switch to use sync version of CPython setup/installation method (#11428) * Use task run to wrap the installation body * Update to use sync version of API * Additional place to fix * Update Python.Included to PR 22 (#11429) Adds function SetupPythonSync to setup python synchronously Co-authored-by: Martin Misol Monzo <[email protected]>
Please Note:
DynamoRevit
repo will need to be cherry-picked into all the DynamoRevit Release branches that Dynamo supports. Contributors will be responsible for cherry-picking their reviewed commits to the other branches after aLGTM
label is added to the PR.Purpose
Regarding https://jira.autodesk.com/browse/REVIT-173181.
Switch to use sync version of CPython setup/installation method as suggested by @mmisol .
If team is OK with this, let's ship the hotfix this way. Notice the little hang only happens first time user trying to evaluate a CPython node
Declarations
Check these if you believe they are true
*.resx
filesReviewers
@DynamoDS/dynamo
FYIs
@mmisol @mjkkirschner @saintentropy