-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Refactor IPackage
#4174
Refactor IPackage
#4174
Conversation
@@ -358,7 +358,8 @@ namespace AppInstaller::CLI::Configuration | |||
{ | |||
if (!package.Version.empty()) | |||
{ | |||
auto versionKeys = searchResult.Matches.at(0).Package->GetAvailableVersionKeys(); | |||
std::shared_ptr<Repository::IPackage> availablePackage = searchResult.Matches.at(0).Package->GetAvailable().at(0); |
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.
Package->GetAvailable().at(0)
What if the version we're looking for is not in the first available source?
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.
This code requires a source name, and at this time there is no way to name a composite source. Thus, there will only ever be one available package.
As I mentioned in the description, this is a case where separating CompositeSource
out from ISource
would be very helpful. But that change would be even larger.
OutputCompletionString(stream, vc.Version); | ||
if (word.empty() || Utility::ICUCaseInsensitiveStartsWith(vc.Version, word)) | ||
{ | ||
OutputCompletionString(stream, vc.Version); |
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.
Does the order in which these are output matter?
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 set a goal of output in "best match order"; aka the order that places the most likely completion first and so forth. I believe that PowerShell's implementation does use the order as the tab completion cycle.
I assume what you are indicating is that the order will change when there are multiple available packages. This is true, but I'm not sure that is incorrect in this case.
@@ -140,7 +140,7 @@ namespace AppInstaller::CLI::Workflow | |||
} | |||
else | |||
{ | |||
auto availableVersion = package->GetAvailableVersion({ pinKey.SourceId, "", "" }); | |||
auto availableVersion = GetAvailableVersionsForInstalledVersion(package, nullptr)->GetVersion({ pinKey.SourceId, "", "" }); |
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.
Could this be GetAvailablePackageFromSource(package, pinKey.sourceId)->GetLatestVersion()
?
@@ -628,7 +629,7 @@ namespace AppInstaller::CLI::Workflow | |||
|
|||
for (size_t i = 0; i < searchResult.Matches.size(); ++i) | |||
{ | |||
auto latestVersion = searchResult.Matches[i].Package->GetLatestAvailableVersion(); | |||
auto latestVersion = GetAvailableVersionsForInstalledVersion(searchResult.Matches[i].Package, nullptr)->GetLatestVersion(); |
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.
Could we add a GetAvailableVersions(ICompositePackage)
so that we don't have to pass nullptr
?
@@ -327,163 +340,127 @@ namespace AppInstaller::Repository | |||
std::shared_ptr<IPackageVersion> m_trackingPackageVersion; | |||
}; | |||
|
|||
// A composite package for the CompositeSource. | |||
struct CompositePackage : public IPackage | |||
// A composite package for the installed package of a CompositePackage. |
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.
"A composite package for [...] a CompositePackage"? Should it just be "A package for [...]"?
// A composite package for the CompositeSource. | ||
struct CompositePackage : public ICompositePackage | ||
{ | ||
CompositePackage(const std::shared_ptr<ICompositePackage>& installedPackage, const std::shared_ptr<ICompositePackage>& availablePackage = {}) |
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.
Maybe add comment that availablePackage
can only include one package?
This comment has been minimized.
This comment has been minimized.
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.
Change
To better reflect the underlying code and continue to move business logic out of the
CompositeSource
, this change refactors theIPackage
interface into 3:IPackageVersionCollection
is simply a set ofIPackageVersion
objects with only the previousIPackage
functions to enumerate them. This enables some code that only wants to inspect versions to use a tighter set of APIs and thus some implementations need not worry about things like the appropriate property values to return.The refactored
IPackage
inherits fromIPackageVersionCollection
and is itself a set of package versions that all come from a single source (as inSource
). It adds the properties and theSource
that the versions are all from.ICompositePackage
is the new search result, resembling the previousIPackage
in what it contains but exposing it more directly. The installedIPackage
object will eventually be able to contain more than one installed version in a future change. The available packages are exposed directly asIPackage
objects, rather than mixing the versions together in theCompositeSource
.The code in
PackageVersionSelection.cpp
extracts the business logic that was insideCompositeSource
previously, as well as providing a few helpers to make the existing code work more succinctly. The refactoring is not attempting to change behavior, but simply make it possible to change behavior more easily and precisely in the future.I would have preferred to go further by splitting
CompositeSource
out into a public type, allowing the other sources to have a simpler model of only ever returningIPackage
results from search. This change would have created an even larger churn though and did not directly contribute towards the goal of supporting future side-by-side work.Also changes the YAML object model to use a non-exceptional function to attempt to convert to an integer.
Validation
Existing regression tests should cover all changes.
Microsoft Reviewers: Open in CodeFlow