DYN-8274 PythonScript With Dispose when Exception

[RobertGlobant20]

Purpose

This test is validating that if there is an exception inside the with statement the resources are disposed correctly.
The Python.Runtime.dll is needed due that we need to changes done in pythonnet project otherwise the test will be failing

Declarations

Check these if you believe they are true

• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated
• This PR contains no files larger than 50 MB
• This PR introduces new feature code involve network connecting and is tested with no-network mode.

Release Notes

This test is validating that if there is an exception inside the with statement the resources are disposed correctly

Reviewers

@aparajit-pratap @zeusongit

FYIs

[github-actions]

See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-8274

[Copilot]

Pull Request Overview

This PR introduces a new test to verify that resources in a PythonScript node are correctly disposed even when an exception occurs inside a with statement. Key changes include:

• Addition of a new .dyn file containing a Python graph that utilizes a context manager for resource disposal.
• Implementation of a new test method in PythonEditTests.cs that manipulates the Python script to trigger and then recover from an exception.

Reviewed Changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File	Description
test/core/python/withDisposeFFITarget.dyn	Introduces a Python graph that uses a context manager to track disposal counts.
test/Libraries/DynamoPythonTests/PythonEditTests.cs	Adds a new test which updates the Python script to trigger an exception and verifies the disposal behavior.

Comments suppressed due to low confidence (1)

test/Libraries/DynamoPythonTests/PythonEditTests.cs:697

• [nitpick] The variable name 'line_update' does not clearly convey that it represents an erroneous function call intended to trigger an exception. Consider renaming it to something like 'erroneousCall' for improved clarity.

            var line_update = "Point.ByCoordinate(10,20)";

[Copilot]

[nitpick] The test relies on hardcoded string replacements for function calls. Consider defining these expected strings as constants or descriptive variables to reduce duplication and improve maintainability.

Suggested change

	script = script.Replace("Point.ByCoordinates(10,20)", line_update);
	script = script.Replace(OriginalPointByCoordinates, line_update);

[zeusongit]

Why is Python.Runtime.dll modified, was there also a change made to CPython3? I thought the change was only for PythonNet3 engine?

[RobertGlobant20]

Why is Python.Runtime.dll modified, was there also a change made to CPython3? I thought the change was only for PythonNet3 engine?

The code fix was done in the pythonnet solution, specifically in the Python.Runtime project, then the only way which I found to make the test to pass is by updating the Python.Runtime.dll in ...Dynamo\extern\Python (otherwise my code is not present and getting an error).

Not sure if the dll should be included or not in this PR or if my PR for pythonnet should be merged first and then create this PR (in some way the Python.Runtime.dll should be updated with my changes).

[zeusongit]

Hey @RobertGlobant20 I did look into this, and I think the fix should end up in PythonNet3Engine repo, the package that adds the PythonNet3 engine also has a Python.Runtime.dll. And from the issue, it seems the bug was not reproduced with CPython3.

[aparajit-pratap]

Hey @RobertGlobant20 I did look into this, and I think the fix should end up in PythonNet3Engine repo, the package that adds the PythonNet3 engine also has a Python.Runtime.dll. And from the issue, it seems the bug was not reproduced with CPython3.

The fix was made in pythonnet repo. I think PythonNet3Engine repo is the Dynamo package, not the Python net implementation.

[zeusongit]

Hey @RobertGlobant20 I did look into this, and I think the fix should end up in PythonNet3Engine repo, the package that adds the PythonNet3 engine also has a Python.Runtime.dll. And from the issue, it seems the bug was not reproduced with CPython3.

The fix was made in pythonnet repo. I think PythonNet3Engine repo is the Dynamo package, not the Python net implementation.

Both packages consumes the pythonnet repo, so I guess the question is which package/engine needs the fix?

[aparajit-pratap]

Hey @RobertGlobant20 I did look into this, and I think the fix should end up in PythonNet3Engine repo, the package that adds the PythonNet3 engine also has a Python.Runtime.dll. And from the issue, it seems the bug was not reproduced with CPython3.

The fix was made in pythonnet repo. I think PythonNet3Engine repo is the Dynamo package, not the Python net implementation.

Both packages consumes the pythonnet repo, so I guess the question is which package/engine needs the fix?

I suppose we need to check if this PR needs to be made to both dynamo_master and dynamo_py3 branches?

[RobertGlobant20]

seems that the job passed successfully here:
https://master-5.jenkins.autodesk.com/job/Dynamo/job/DynamoSelfServe/job/pullRequestValidation/18088/

[RobertGlobant20]

@aparajit-pratap based in our slack conversation about the different warning when selecting the CPython3 engine vs the PythonNet3 engine when there is an exception inside the with statement, it's ok to merge this PR to master?

Also is important to mention that the Python.Runtime.dll was generated using the pythonnet.15 solution and using the dynamo_master branch selecting the configuration ReleaseWinPy3