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

Pkg builtin bug #12308

Merged
merged 27 commits into from
Dec 7, 2021
Merged

Pkg builtin bug #12308

merged 27 commits into from
Dec 7, 2021

Conversation

pinzart90
Copy link
Contributor

Allow users to download a non-built in package if the built-in package is not Loaded (Unloaded or Error).

Release Notes

Allow users to download a non-built in package if the built-in package is not Loaded (Unloaded or Error).

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

@mjkkirschner
Copy link
Member

Is this fixing the case which was the whole reason for allowing a built-in package to be unloaded?

@pinzart90
Copy link
Contributor Author

a built-in package to be unloaded?

There are still a couple of issues with this scenario (working on it)
But pretty much yes. It will allow users to download a package which is in conflict with a built-in (only when unloaded).
The warning message says:

You can try disabling loading packages from built-in package paths, or unload the conflicting package, then restart {2} and download {0} again.

Without this PR...even if you follow the stepss described in the warning message...you still will not be able to install the desired package

@mjkkirschner
Copy link
Member

It looks good but there are 2 failing tests.

@pinzart90
Copy link
Contributor Author

Best to disable whitespaces in the PR diff viewer

Copy link
Contributor

@sm6srw sm6srw left a comment

Choose a reason for hiding this comment

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

LGTM!

return;
if (!dependencyVersionHeaders.Any(x => x.name == name))
{// Add the main package if it does not exist
dependencyVersionHeaders.Add(package);

This comment was marked as resolved.

if (name.Equals(localPkgWithSameName.Name))
{// Main package has a duplicate in local packages
duplicatePackage = localPkgWithSameName;
break;// Download will not be able to continue
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@aparajit-pratap can you confirm that this was an intended change in your previous PR ?
If the main package (the one that the user wants to download) has a conflict with an existing package ...then download will not be possible without the user having to intervene (remove existing or disabling package paths etc)

It seems like this was possible before ... if the existing package had no assemblies loaded (or was not in use)

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you mean that before, we allowed multiple packages of different versions but the same name to be installed at the same time if they didn't have assemblies?

Copy link
Contributor Author

@pinzart90 pinzart90 Nov 30, 2021

Choose a reason for hiding this comment

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

I think your PR allowed it too.
My question is :
Should the user be able to immediately download (without restart) another version of an already installed package (that has no assemblies loaded) ? Uninstalling the existing package should be possible without restart.
My PR disallows this behavior...

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think that we should allow download. If my PR allowed it then it probably was an oversight on my part.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I do not understand why we should not allow it though...
Just so that we do not complicate the workflow too much ?

Copy link
Contributor

@aparajit-pratap aparajit-pratap Dec 1, 2021

Choose a reason for hiding this comment

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

Well, yes. If it was allowed after my PR, it was purely unintentional. As you say, I think it will complicate things just because the user will start seeing apparently duplicate nodes in the library and not know which node comes from which package version. We could discuss this as a team if you prefer. I would also like to confirm what the behavior was before 2.13. If we didn't allow it before, I think we should just keep it that way.

Copy link
Contributor

@aparajit-pratap aparajit-pratap Dec 6, 2021

Choose a reason for hiding this comment

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

I misunderstood this scenario. My previous comment assumed that you will not be uninstalling the conflicting package but it looks like you'll first uninstall it and only then install the new one, which I think is okay.

if (dialogResult == MessageBoxResult.OK)
{
// mark for uninstallation
duplicatePackage.MarkForUninstall(DynamoViewModel.Model.PreferenceSettings);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

should we be returning with true here ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think so as we will not be going ahead with the download.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What when duplicatePackage has no assemblies loaded. I think this may be a regression ...

Copy link
Contributor

@aparajit-pratap aparajit-pratap Dec 1, 2021

Choose a reason for hiding this comment

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

Again, here it could complicate things as well as we could end up with multiple nodes of the same name from different package versions. However, if this is confirmed to be a regression, then I agree, let's not break it - check if it's a non-assembly package, then install it (return true).

if (dialogResult == MessageBoxResult.OK)
{
// mark for uninstallation
duplicatePackage.MarkForUninstall(DynamoViewModel.Model.PreferenceSettings);
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think so as we will not be going ahead with the download.

if (name.Equals(localPkgWithSameName.Name))
{// Main package has a duplicate in local packages
duplicatePackage = localPkgWithSameName;
break;// Download will not be able to continue
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you mean that before, we allowed multiple packages of different versions but the same name to be installed at the same time if they didn't have assemblies?

Copy link
Contributor

@aparajit-pratap aparajit-pratap left a comment

Choose a reason for hiding this comment

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

Other than updating the code comments for the WarnAboutDuplicatePackageConflicts function, LGTM!

{
dialogResult = MessageBoxService.Show(String.Format(Resources.MessageAlreadyInstallDynamo,
DynamoViewModel.BrandingResourceProvider.ProductName, dupPkg, packageToDownload),
Resources.CannotDownloadPackageMessageBoxTitle,
Copy link
Contributor

Choose a reason for hiding this comment

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

Does CannotDownloadPackageMessageBoxTitle title still make sense now as the package can now be installed right?

Copy link
Contributor Author

@pinzart90 pinzart90 Dec 6, 2021

Choose a reason for hiding this comment

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

replaced with pre-existing PackagesInUseConflictMessageBoxTitle

Package has conflicts with one or more packages in use.

Copy link
Contributor

@aparajit-pratap aparajit-pratap left a comment

Choose a reason for hiding this comment

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

Just one question about the msg box title.

@pinzart90 pinzart90 merged commit c365cc4 into master Dec 7, 2021
@pinzart90 pinzart90 deleted the pkg_builtin_bug branch December 7, 2021 14:55
pinzart90 added a commit that referenced this pull request Dec 7, 2021
* filter only loaded blt in packages

* Update PackageManagerUITests.cs

* Update PackageManagerClientViewModel.cs
@pinzart90 pinzart90 mentioned this pull request Dec 7, 2021
8 tasks
OliverEGreen pushed a commit to OliverEGreen/Dynamo that referenced this pull request Dec 8, 2021
* filter only loaded blt in packages

* Update PackageManagerUITests.cs

* Update PackageManagerClientViewModel.cs
pinzart90 added a commit that referenced this pull request Dec 8, 2021
* Pkg builtin bug (#12308)

* filter only loaded blt in packages

* Update PackageManagerUITests.cs

* Update PackageManagerClientViewModel.cs

* remove bad merge

Co-authored-by: pinzart <[email protected]>
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