DYN-3572 std.lib should be visible in manage node and package path UI

[sm6srw]

Purpose

DYN-3572 std.lib should be visible in manage node and package path UI

Note: This will also fix DYN-3570 and partially fix DYN-3571 as it will stop Packet manager from downloading packages to the Standard Library directory (but it is till possible to download to the %ProgramData% directory).

This pull request does:

• filters out the standard library directory token from the directory list in in PathManager.
• add the standard library directory token as the first folder in DynamoModel.
• insert the standard library directory token as the first folder if missing in DynamoModel.
• add Standard Library to the resources in PackagePathViewModel so it can be translated.
• substitute the standard library token with the Standard Library resource when the dialog initializes.
• prevent the standard library entry from being deleted in PackagePathViewModel.
• prevent the standard library entry from being updated in PackagePathViewModel.
• update the wording in the Package Path dialog.
• show the Standard Library with Italic font type if Standard Library is disabled.
• substitute the translated Standard Library resource with the standard library token when changes are committed in the dialog.
• make sure that the DefaultPackagesDirectory property points to the first non standard library entry in PackageLoader
• add standard library first if missing in PackageLoader
• substitute the standard library token with the runtime standard library directory in PackageLoader

Normal dialog:

Dialog when Standard Library is disabled:

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

[aparajit-pratap]

In this dialog, can we change the description to say that the first path below "Standard Library" is the default save location. Can we also explain that the Standard Library is the location from where packages will be loaded first followed by the rest of the paths.

[sm6srw]

In this dialog, can we change the description to say that the first path below "Standard Library" is the default save location. Can we also explain that the Standard Library is the location from where packages will be loaded first followed by the rest of the paths.

Good point. I totally missed that text. I will try to come up with some wording that covers the new behavior.

[mjkkirschner]

In this dialog, can we change the description to say that the first path below "Standard Library" is the default save location. Can we also explain that the Standard Library is the location from where packages will be loaded first followed by the rest of the paths.

Good point. I totally missed that text. I will try to come up with some wording that covers the new behavior.

this is actually covered in:
https://jira.autodesk.com/browse/DYN-3571

but fixing it now is even better.

I think it may ultimately change, but it's good to make it as correct as possible IMO.

[mjkkirschner]

@sm6srw - theres one AC that was included in the task that I don't see in your description:
if std.lib is disabled, the entry in the ui should appear disabled - what do you think of this one? We could also leave this for later depending on if we expose those options to the UI as well.

[mjkkirschner]

This looks pretty solid to me - one thought that occurs to me is that depending on our final strategy for dealing with conflicts during package install (as opposed to Dynamo startup) - that we may reevaluate std.lib's location (first or last), additionally feedback from UX may lead us to rethink this anyway.

Given that, do you think the position is difficult to change after this PR or it will be pretty straightforward? - I was wondering if the logic could be abstracted into a position field somewhere we could set.

[sm6srw]

@sm6srw - theres one AC that was included in the task that I don't see in your description:
if std.lib is disabled, the entry in the ui should appear disabled - what do you think of this one? We could also leave this for later depending on if we expose those options to the UI as well.

Thanks, I missed this one. I will take a look.

[sm6srw]

This looks pretty solid to me - one thought that occurs to me is that depending on our final strategy for dealing with conflicts during package install (as opposed to Dynamo startup) - that we may reevaluate std.lib's location (first or last), additionally feedback from UX may lead us to rethink this anyway.

Given that, do you think the position is difficult to change after this PR or it will be pretty straightforward? - I was wondering if the logic could be abstracted into a position field somewhere we could set.

It is a small change. It happens in two places right now. But I have been thinking that it might be possible to remove that logic all together now from the PackageLoader with these changes. I think I will take a look at that.