Skip to content
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

DYN-7535 Record python engine package information in graphs when using engines served from them #15535

Merged
merged 12 commits into from
Oct 17, 2024

Conversation

zeusongit
Copy link
Contributor

Purpose

A leaner approach to record package dependency for a python engine, and trigger workspace dependency.

Opening a graph with PythonEngine not loaded in Dynamo:

DynamoSandbox_0MUnzezPDs

Opening a graph with PythonEngine loaded in Dynamo, but with a version mis-match:

DynamoSandbox_q0lBECS4VN.mp4

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • 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
  • All tests pass using the self-service CI.
  • 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

Release Notes

  • Record python engine package information in graphs when using engines served from them

Reviewers

@DynamoDS/dynamo

FYIs

@pinzart90

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

github-actions bot commented Oct 9, 2024

UI Smoke Tests

Test: success. 11 passed, 0 failed.
TestComplete Test Result
Workflow Run: UI Smoke Tests
Check: UI Smoke Tests

/// The method returns the assembly name from which the node originated.
/// </summary>
/// <returns>Assembly Name</returns>
internal virtual AssemblyName GetNameOfAssemblyReferencedByNode()
Copy link
Member

@mjkkirschner mjkkirschner Oct 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe a better name is GetOwningAssemblyNameOfNodeModel - referenced by node sounds like a dependency of the node to me anyway.

AssemblyName assemblyName = null;

var descriptor = this.Controller.Definition;
if (descriptor.IsPackageMember)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would be valid even if this was not a packaged node -right?

Copy link
Contributor Author

@zeusongit zeusongit Oct 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it would be, but I think the intent is to return null for non-packaged nodes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then I think your summary/returns could be updated to reflect that / a test should be added encoding that behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, just want to add that this was the default behavior, I did not add this code but moved it inside the base class. So whatever it was doing before will still be applied.

{
var assemName = AssemblyName.GetAssemblyName(assem.Location);
OnMessageLogged(LogMessage.Info(
string.Format("{0} contains the python engine library {1}, which has already been loaded " +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mjkkirschner
Copy link
Member

nice, this seems much cleaner, and should be testable by creating a graph with a bunch of python nodes in it and checking the NodePackageDictionary?

@zeusongit
Copy link
Contributor Author

nice, this seems much cleaner, and should be testable by creating a graph with a bunch of python nodes in it and checking the NodePackageDictionary?

Sure, added a test

@zeusongit
Copy link
Contributor Author

One sporadic test failing, has been failing for most PRs

@zeusongit
Copy link
Contributor Author

@zeusongit zeusongit merged commit da01d40 into DynamoDS:master Oct 17, 2024
23 of 24 checks passed
@QilongTang QilongTang added this to the 3.4 milestone Oct 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants