Efficiently solve dependency metadata on install#10544
Efficiently solve dependency metadata on install#10544mmisol merged 10 commits intoDynamoDS:masterfrom
Conversation
…eader_package_install
| </data> | ||
| <data name="MessageFailedToDownloadPackageVersion" xml:space="preserve"> | ||
| <value>Failed to download version {0} of package with id: {1}. Please try again and report the package if you continue to have problems.</value> | ||
| <comment>Message box content. {0} = 1.2.3, {1} = 57d576e8f615e7725800001d</comment> |
There was a problem hiding this comment.
No, just examples of what kind of text is expected in the placeholders. I thought that's a good way of communicating that to whoever does the text translations.
|
|
||
| var pmExtension = DynamoViewModel.Model.GetPackageManagerExtension(); | ||
| var firstOrDefault = pmExtension.PackageLoader.LocalPackages.FirstOrDefault(pkg => pkg.Name == packageDownloadHandle.Name); | ||
| var firstOrDefault = pmExtension.PackageLoader.LocalPackages.FirstOrDefault(pkg => pkg.ID == packageDownloadHandle.Id); |
There was a problem hiding this comment.
hmm, do you think this could change any existing behavior?
There was a problem hiding this comment.
I don't think so. I tested installing packages from both the search and the workspace dependency extension to be sure.
|
|
||
| if (packageDownloadHandle.Extract(DynamoViewModel.Model, downloadPath, out dynPkg)) | ||
| { | ||
| var p = Package.FromDirectory(dynPkg.RootDirectory, DynamoViewModel.Model.Logger); |
There was a problem hiding this comment.
why is this no longer required?
There was a problem hiding this comment.
This was already being done inside packageDownloadHandle.Extract, but only for the workspace dependency extension code path. I unified both code paths and now it's always done inside Extract, which returns a boolean to report success.
|
@mmisol looks good to me! |
| x => x.Item2.contents.Contains(PackageManagerClient.PackageContainsPythonScriptsConstant)); | ||
| var containsBinariesOrPythonScripts = dependencyVersionHeaders.Any(x => | ||
| x.contents.Contains(PackageManagerClient.PackageContainsBinariesConstant) || | ||
| x.contains_binaries || |
There was a problem hiding this comment.
We would get some minor performance gains by moving the contains_binaries test before the Contains() check.
| /// <summary> | ||
| /// Returns a newline delimited string representing the package name and version of the argument | ||
| /// </summary> | ||
| [Obsolete("No longer used. Remove in 3.0.")] |
There was a problem hiding this comment.
@mjkkirschner I thought we made it clear somewhere that these APIs are not part of Dynamo SDK? If not, let's do that..
There was a problem hiding this comment.
@QilongTang we only made that statement in new extension binaries like WorkspaceReferencesExtension - this is a public method in DynamoCoreWPF - we can't remove this method now without some of the other work on reorganizing or componentizing the API we've been discussing.
There was a problem hiding this comment.
Thank you for clarifying. I thought this is in WorkspaceReference project. My bad
| /// <param name="header"></param> | ||
| /// <param name="version"></param> | ||
| /// <returns></returns> | ||
| [Obsolete("No longer used. Remove in 3.0.")] |
There was a problem hiding this comment.
@mmisol I believe Internal APIs can be removed anytime. Unless it is used in a lot of other projects?
| public string Name { get { return Header != null ? Header.name : _name; } set { _name = value; } } | ||
|
|
||
| private string _id; | ||
| public string Id { get { return Header != null ? Header._id : _id; } set { _id = value; } } |
There was a problem hiding this comment.
for public properties please add /// summaries - also, should this really be public? Do we intend for others extension authors / dynamo integrators to use this?
There was a problem hiding this comment.
This is used in DynamoCoreWpf so I'll add comments for it. I don't think someone might want to extend it in some way. This is used as a view model for the installed dependencies when installing a package from the search.
There was a problem hiding this comment.
if it's only to be used by us - maybe we can make it internal and use the internalsVisibleTo attribute, my feeling is that we should be much more deliberate about what constitutes our public api. What do you think?
There was a problem hiding this comment.
My opinion is that using InternalsVisibleTo is more of a hack than a good practice. Making something public shouldn't make it "written in stone". I think we should identify exactly what we want our extension points to be instead, and only make promises of backwards compatibility for those.
Purpose
When resolving dependencies from the workspace dependency extension,
the entire metadata of dependent packages was requested. However, only
information about the version was truly needed, and for packages with a
lot of versions this was causing latency issues.
Now only the package version of dependencies is obtained. As a result,
several code changes were needed, as part of the code path is shared
with the standard installation of packages through search, but with
different data requirements in each case. Several properties and
functions no longer used were marked as 'Obsolete'.
Added some basic unit tests for the new functions in package manager
client.
Declarations
Check these if you believe they are true
*.resxfilesReviewers
@mjkkirschner @zeusongit
FYIs
@reddyashish