-
Notifications
You must be signed in to change notification settings - Fork 676
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
Add package namespace configuration reading and processing logic #4009
Add package namespace configuration reading and processing logic #4009
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Some comments on constructor.
test/NuGet.Core.Tests/NuGet.Configuration.Test/SettingsFileParsingTests/NamespaceItemTests.cs
Show resolved
Hide resolved
src/NuGet.Core/NuGet.Configuration/PackageNamespaces/PackageNamespacesConfiguration.cs
Outdated
Show resolved
Hide resolved
return newItem; | ||
} | ||
|
||
public override bool Equals(object other) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to implement IEquatable<>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, there is no need for it.
In practice, it'd only save in boxing. Not sure it's be a huge gain in the context of configurations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least for me, it helps me in understanding code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that PackageSource
element implements IEquatable
interface
public class PackageSource : IEquatable<PackageSource> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how implementing IEquatable improves code understanding here?
I see that PackageSource element implements IEquatable interface
I get that. If we look at many other items like:
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Configuration/Settings/Items/AddItem.cs
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Configuration/Settings/Items/AuthorItem.cs
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Configuration/Settings/Items/CertificateItem.cs
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Configuration/Settings/Items/ClearItem.cs
They don't implement it. So precedent is spotty.
IEquatable was primarily added for structs, where Equals
compares the ref instead.
src/NuGet.Core/NuGet.Configuration/Settings/Items/PackageSourceNamespacesItem.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Core/NuGet.Configuration/Settings/Items/PackageSourceNamespacesItem.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Core/NuGet.Configuration/Settings/Items/PackageSourceNamespacesItem.cs
Outdated
Show resolved
Hide resolved
Thanks @dominoFire, addressed the feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great start Nikolche. Few comments to start with.
_settings.Remove(ConfigurationConstants.PackageNamespaces, packageSourceNamespace); | ||
} | ||
// An error means the item doesn't exist or is in a machine wide config, therefore just ignore it | ||
catch { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
catch { } | |
catch (InvalidOperationException) { } |
Can we catch InvalidOperationException
instead of a generic exception because _settings.Remove
throws only InvalidOperationException
exception in few cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could throw some IO exceptions if the config is not editable.
We wouldn't do anything with the exception anyways.
src/NuGet.Core/NuGet.Configuration/Settings/Items/PackageSourceNamespacesItem.cs
Outdated
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/PackageNamespacesProviderTests.cs
Show resolved
Hide resolved
{ | ||
public override string ElementName => ConfigurationConstants.Namespace; | ||
|
||
public string Id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should add additional validation to Id
attribute because it is a prefix of Package ID
which has few constraints.
NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Utility/PackageIdValidator.cs
Lines 13 to 16 in f298d71
public const int MaxPackageIdLength = 100; | |
private static readonly Regex IdRegex = new Regex(pattern: @"^\w+([.-]\w+)*$", | |
options: RegexOptions.IgnoreCase | RegexOptions.ExplicitCapture | RegexOptions.CultureInvariant, | |
matchTimeout: TimeSpan.FromSeconds(10)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant to create a follow up issue for this.
Created an issue: NuGet/Home#10783
A couple of reasons:
- I want to unblock the next set of work.
- We haven't explicitly designed for the invalid namespace experience. Do we fail early? Warn and continue? Ignore? We can cover this Thursday.
- Given that this is a configuration only change, it wasn't super clear where the most convenient location to validate this is.
src/NuGet.Core/NuGet.Configuration/Settings/Items/NamespaceItem.cs
Outdated
Show resolved
Hide resolved
return newItem; | ||
} | ||
|
||
public override bool Equals(object other) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that PackageSource
element implements IEquatable
interface
public class PackageSource : IEquatable<PackageSource> |
src/NuGet.Core/NuGet.Configuration/Settings/Items/NamespaceItem.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Core/NuGet.Configuration/Settings/Items/NamespaceItem.cs
Outdated
Show resolved
Hide resolved
Ready for another review; @kartheekp-ms @dominoFire |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad to see this one is going forward.
To start I have few comments.
return packageNamespacesSection.Items.OfType<PackageSourceNamespacesItem>().ToList(); | ||
} | ||
|
||
public void Remove(IReadOnlyList<PackageSourceNamespacesItem> packageSourceNamespaces) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are remove/update scenarios are covered in spec?
In what scenarios is it going to happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will be a command soon. Tracked in NuGet/Home#10735.
Implementing the Get/Add/Update/Remove in one pass seemed like a natural extension.
Keep in mind that this API is currently internal only, so it carries no risk as of now.
We will need it by the time we ship the feature.
test/NuGet.Core.Tests/NuGet.Configuration.Test/PackageNamespacesProviderTests.cs
Outdated
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/PackageNamespacesProviderTests.cs
Outdated
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/PackageNamespacesProviderTests.cs
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/PackageNamespacesProviderTests.cs
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/PackageNamespacesProviderTests.cs
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/PackageNamespacesProviderTests.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signing off. Please address comment on string resource. Thanks!
src/NuGet.Core/NuGet.Configuration/Settings/Items/PackageNamespacesSourceItem.cs
Outdated
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/SettingsFileParsingTests/NamespaceItemTests.cs
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.Configuration.Test/SettingsFileParsingTests/OwnersItemTests.cs
Outdated
Show resolved
Hide resolved
cbce607
to
06362a5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job.
One tiny comment.
Bug
Fixes: NuGet/Home#10725
Regression? Last working version:
Description
Design at https://github.com/NuGet/Home/blob/package-namespaces/proposed/2021/PackageNamespaces.md.
Add the required models to read the current iteration of the configuration for namespaces.
This adds a few things:
namespace
andpackageSource
under packageNamespaces.Note that these APIs are not final, especially the PackageNamespaceConfiguration one. I just don't want to overdo it before we under the needs of the APIs better.
Wait a feature branch?
Yes - https://github.com/NuGet/Client.Engineering/pull/910
PR Checklist
PR has a meaningful title
PR has a linked issue.
Described changes
Tests
Documentation