New API Function from PluginManifest and PluginManager #3419
Conversation
This comment has been minimized.
This comment has been minimized.
|
🥷 Code experts: jjw24 jjw24 has most 🧠 knowledge in the files. See details
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame:
Knowledge based on git-blame: To learn more about /:\ gitStream - Visit our Docs |
|
Be a legend 🏆 by adding a before and after screenshot of the changes you made, especially if they are around UI/UX. |
📝 WalkthroughWalkthroughThis pull request introduces several enhancements and refactorings related to plugin management in Flow Launcher. It includes the addition of new using directives, updates to namespace references, and modifications to method signatures and variable declarations. Key changes involve the introduction of new API methods for managing plugins, including installation, updating, and uninstallation. Calls to legacy plugin management methods have been replaced with updated API calls, reflecting a transition to a more centralized approach for plugin operations across the application. Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant VM as SettingsPanePluginStoreViewModel
participant API as PublicAPIInstance
participant PM as PluginManager
U->>VM: Initiate plugin update
VM->>API: UpdatePluginManifestAsync(usePrimaryUrlOnly)
API->>PM: Forward request via Context.API
PM-->>API: Return update result
API-->>VM: Return updated plugin manifest
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (5)
Flow.Launcher.Plugin/UserPlugin.cs (3)
8-13: Consider using nullable reference types for string properties.Since C# 8.0, it's recommended to use nullable reference types to avoid null reference exceptions. For a model class that will be deserialized from JSON, it's important to handle potential null values.
/// <summary> /// Unique identifier of the plugin /// </summary> -public string ID { get; set; } +public string? ID { get; set; }Consider adding the nullable annotation context to the file:
using System; +#nullable enable namespace Flow.Launcher.Plugin
8-79: Consider adding validation for required properties.For a plugin model, certain properties like ID and Name are likely required. Consider adding validation to ensure these properties are not null or empty, either through a constructor, initialization, or validation method.
You could add a validation method like:
public bool Validate() { return !string.IsNullOrEmpty(ID) && !string.IsNullOrEmpty(Name) && !string.IsNullOrEmpty(Version); }Or you could initialize properties with empty strings in a constructor:
public UserPlugin() { ID = string.Empty; Name = string.Empty; Description = string.Empty; Author = string.Empty; Version = string.Empty; Language = string.Empty; Website = string.Empty; UrlDownload = string.Empty; UrlSourceCode = string.Empty; LocalInstallPath = string.Empty; IcoPath = string.Empty; }
35-38: Improve the XML documentation reference.The
<see cref="AllowedLanguage"/>reference in the Language property documentation doesn't appear to refer to a visible type in this file. Ensure that this reference is correct and accessible, or provide more context about the allowed languages./// <summary> -/// Allow language of the plugin <see cref="AllowedLanguage"/> +/// Language of the plugin (e.g., C#, Python, etc.) /// </summary> public string Language { get; set; }Alternatively, if AllowedLanguage is defined elsewhere:
/// <summary> /// Allow language of the plugin <see cref="AllowedLanguage"/> /// </summary> public string Language { get; set; }Flow.Launcher/SettingPages/ViewModels/SettingsPanePluginStoreViewModel.cs (2)
15-21: Consider adding null-handling logicWhile you've correctly used the null-conditional operator (
?.) withGetPluginManifest(), consider adding explicit handling in case the manifest is null - perhaps returning an empty list instead of null to prevent potential null reference exceptions further down the chain.public IList<PluginStoreItemViewModel> ExternalPlugins => - App.API.GetPluginManifest()?.Select(p => new PluginStoreItemViewModel(p)) + App.API.GetPluginManifest()?.Select(p => new PluginStoreItemViewModel(p)) .OrderByDescending(p => p.Category == PluginStoreItemViewModel.NewRelease) .ThenByDescending(p => p.Category == PluginStoreItemViewModel.RecentlyUpdated) .ThenByDescending(p => p.Category == PluginStoreItemViewModel.None) .ThenByDescending(p => p.Category == PluginStoreItemViewModel.Installed) - .ToList(); + .ToList() ?? new List<PluginStoreItemViewModel>();
23-30: Consider adding error handlingThe
RefreshExternalPluginsAsyncmethod doesn't include any error handling. IfUpdatePluginManifestAsyncthrows an exception, it would propagate up the call stack. Consider adding a try-catch block to handle potential exceptions gracefully, especially since this is an async operation that might involve network requests.[RelayCommand] private async Task RefreshExternalPluginsAsync() { + try + { if (await App.API.UpdatePluginManifestAsync()) { OnPropertyChanged(nameof(ExternalPlugins)); } + } + catch (System.Exception ex) + { + // Log the error or show a message to the user + Log.Exception($"Failed to refresh external plugins", ex); + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
Flow.Launcher.Core/ExternalPlugins/CommunityPluginSource.cs(1 hunks)Flow.Launcher.Core/ExternalPlugins/CommunityPluginStore.cs(1 hunks)Flow.Launcher.Core/ExternalPlugins/PluginsManifest.cs(3 hunks)Flow.Launcher.Core/ExternalPlugins/UserPlugin.cs(0 hunks)Flow.Launcher.Core/Plugin/PluginManager.cs(2 hunks)Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs(1 hunks)Flow.Launcher.Plugin/UserPlugin.cs(1 hunks)Flow.Launcher/PublicAPIInstance.cs(2 hunks)Flow.Launcher/SettingPages/ViewModels/SettingsPanePluginStoreViewModel.cs(2 hunks)Flow.Launcher/ViewModel/PluginStoreItemViewModel.cs(0 hunks)Plugins/Flow.Launcher.Plugin.PluginsManager/ContextMenu.cs(1 hunks)Plugins/Flow.Launcher.Plugin.PluginsManager/Flow.Launcher.Plugin.PluginsManager.csproj(1 hunks)Plugins/Flow.Launcher.Plugin.PluginsManager/Main.cs(3 hunks)Plugins/Flow.Launcher.Plugin.PluginsManager/PluginsManager.cs(20 hunks)Plugins/Flow.Launcher.Plugin.PluginsManager/Utilities.cs(1 hunks)
💤 Files with no reviewable changes (2)
- Flow.Launcher/ViewModel/PluginStoreItemViewModel.cs
- Flow.Launcher.Core/ExternalPlugins/UserPlugin.cs
🧰 Additional context used
🧬 Code Definitions (4)
Flow.Launcher.Core/Plugin/PluginManager.cs (2)
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (1)
PluginModified(371-371)Flow.Launcher/PublicAPIInstance.cs (1)
PluginModified(363-363)
Plugins/Flow.Launcher.Plugin.PluginsManager/PluginsManager.cs (3)
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (5)
LogException(234-234)PluginModified(371-371)InstallPlugin(393-393)ShowMsgError(84-84)GetTranslation(135-135)Flow.Launcher/PublicAPIInstance.cs (5)
LogException(203-204)PluginModified(363-363)InstallPlugin(368-369)ShowMsgError(109-110)GetTranslation(171-171)Flow.Launcher.Core/Plugin/PluginManager.cs (3)
PluginModified(457-460)InstallPlugin(469-472)InstallPlugin(483-555)
Flow.Launcher/PublicAPIInstance.cs (2)
Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (5)
Task(72-72)Task(169-169)IReadOnlyList(362-362)PluginModified(371-371)InstallPlugin(393-393)Flow.Launcher.Core/Plugin/PluginManager.cs (5)
PluginModified(457-460)PluginManager(23-627)PluginManager(143-149)InstallPlugin(469-472)InstallPlugin(483-555)
Flow.Launcher.Plugin/UserPlugin.cs (1)
Plugins/Flow.Launcher.Plugin.PluginsManager/Utilities.cs (1)
UserPlugin(62-80)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: gitStream.cm
🔇 Additional comments (41)
Flow.Launcher.Core/ExternalPlugins/CommunityPluginStore.cs (1)
5-5: Import addition supports centralized plugin management.The addition of the
Flow.Launcher.Pluginnamespace import aligns with the PR's objective of refactoring plugin management functionality. This allowsCommunityPluginStoreto directly access types from the Plugin namespace, specifically theUserPluginclass referenced in the code.Flow.Launcher.Core/ExternalPlugins/CommunityPluginSource.cs (1)
3-3: Import addition supports centralized plugin management.The addition of the
Flow.Launcher.Pluginnamespace import is consistent with the PR's objective of centralizing plugin management functionality. This allows direct access to theUserPlugintype that's being used in theFetchAsyncmethod.Plugins/Flow.Launcher.Plugin.PluginsManager/ContextMenu.cs (1)
1-1: Import removal is part of plugin management refactoring.The removal of the
Flow.Launcher.Core.ExternalPluginsimport is appropriate sinceUserPluginis now directly accessible from the current namespace (Flow.Launcher.Plugin.PluginsManager). This change aligns with the PR objective of centralizing plugin management functionality and reducing direct dependencies on theExternalPluginsnamespace.Plugins/Flow.Launcher.Plugin.PluginsManager/Utilities.cs (1)
1-1: Import removal is part of plugin management refactoring.The removal of the
Flow.Launcher.Core.ExternalPluginsimport is consistent with the PR's objective of centralizing plugin management functionality. TheUserPlugintype used in theGetPluginInfoFromZipmethod is now accessible from the current namespace.Plugins/Flow.Launcher.Plugin.PluginsManager/Flow.Launcher.Plugin.PluginsManager.csproj (1)
38-41: Good addition of SharpZipLib dependency.Adding the SharpZipLib package provides necessary ZIP file handling capabilities for the new plugin management functionality. This aligns with the PR objectives that include methods for installing, updating, and uninstalling plugins which would require ZIP file operations.
Flow.Launcher.Core/Plugin/PluginManager.cs (2)
457-460: Good parameter naming change.Renaming the parameter from
uuidtoidis a positive change that makes the method signature more consistent with the API interface definition and other parameter names in the codebase.
516-530: Improved code formatting.The default plugin IDs list has been reformatted with proper indentation and line breaks, which improves readability while maintaining the same functionality.
Flow.Launcher.Core/ExternalPlugins/PluginsManifest.cs (4)
5-6: Appropriate namespace additions.Adding the required namespaces for dependency injection and plugin interfaces supports the updated implementation for exception logging and API access.
21-21: Good practice: Adding readonly modifier.Adding the
readonlymodifier to thefetchTimeoutfield is a good practice as it prevents the value from being accidentally changed after initialization.
25-25: Parameter order improvement.Reordering the parameters to place
usePrimaryUrlOnlyfirst is logical since it's the primary functional parameter, whiletokenis more of an infrastructure concern. Both parameters have default values, so this change won't break existing code.
47-47: Improved exception logging with dependency injection.Switching from direct
Log.Exceptioncalls to using the API through dependency injection centralizes logging and aligns with modern DI practices. This change is consistent with the architectural improvements introduced in this PR.Plugins/Flow.Launcher.Plugin.PluginsManager/Main.cs (4)
6-7: Appropriate using directives for ViewModel and View references.These added using directives are correctly added to support access to the ViewModels and Views within the PluginsManager namespace.
13-13: Changed Context property from instance to static to improve accessibility.The property is now static, which allows access without requiring an instance reference. This change supports the broader API refactoring being introduced in this PR where Context needs to be accessed from various places.
36-36: Updated to use the new API interface for updating plugin manifest.This change correctly replaces the direct call to
PluginsManifest.UpdateManifestAsync()with the new API methodContext.API.UpdatePluginManifestAsync(), which aligns with the PR objective of centralizing plugin management functions in the API.
57-57: Updated to use API-based fuzzy search.This change correctly replaces the direct call to
StringMatcher.FuzzySearchwithContext.API.FuzzySearch, maintaining consistency with the API-based approach being used for other functionality.Plugins/Flow.Launcher.Plugin.PluginsManager/PluginsManager.cs (11)
15-15: Renamed constant for improved code clarity.Renaming
ziptoZipSuffixprovides better semantic meaning and follows proper naming conventions for constants.
17-17: Added class name constant for consistent logging.Adding a static readonly string for the class name is a good practice for ensuring consistent logging throughout the class and avoiding string literals.
51-51: Updated to use C# target-typed new expressions.The code now uses the shorthand
new()syntax introduced in C# 9, which improves readability while maintaining type safety.Also applies to: 63-63, 75-75, 276-276, 552-552
169-169: Standardized exception logging through the API.The code now consistently uses
Context.API.LogException(ClassName, message, exception)for all exception logging, which provides better centralized error handling and consistent logging format.Also applies to: 179-179, 366-367, 438-438, 655-655, 662-662, 669-669, 743-743
237-237: Updated to use the new API method for updating plugin manifest.This change correctly uses
Context.API.UpdatePluginManifestAsync()instead of direct calls toPluginsManifest.UpdateManifestAsync(), aligning with the PR objective of centralizing plugin operations through the API.Also applies to: 602-602
250-250: Updated to use API methods for getting plugin manifest and checking modifications.The code now uses
Context.API.GetPluginManifest()andContext.API.PluginModified(id)instead of directly accessingPluginsManifest.UserPluginsand plugin modification flags, which improves encapsulation and follows the new API design.Also applies to: 612-613
341-342: Updated to use the new API method for updating plugins.The code now uses
Context.API.UpdatePluginAsync()to update plugins, which aligns with the PR's objective of centralizing plugin management through the API.Also applies to: 433-434
646-646: Updated to use the new API method for installing plugins.The code now uses
Context.API.InstallPlugin()instead of directly callingPluginManager.InstallPlugin(), following the new API-centric approach for plugin management.
739-739: Updated to use the new API method for uninstalling plugins.The code now uses
Context.API.UninstallPluginAsync()for plugin uninstallation, which is consistent with the PR's objective of centralizing plugin operations through the API.
498-498: Updated string format to use named constant.The code now uses the
ZipSuffixconstant in the string format operation instead of a string literal, improving maintainability and consistency.
605-605: Updated to use the named constant for file extension check.The code now uses the
ZipSuffixconstant instead of a string literal when checking file extensions, ensuring consistency throughout the codebase.Flow.Launcher/PublicAPIInstance.cs (7)
31-31: Added appropriate using directive for external plugins.This import of
Flow.Launcher.Core.ExternalPluginsis necessary to access thePluginsManifestclass used in the new API methods.
358-359: Added new API method for updating plugin manifest.This method correctly implements the
UpdatePluginManifestAsyncmethod declared in theIPublicAPIinterface by delegating to the existingPluginsManifest.UpdateManifestAsyncmethod. This addition aligns with the PR objectives.
361-361: Added new API method for retrieving plugin manifest.This method correctly implements the
GetPluginManifestmethod declared in theIPublicAPIinterface by returning the existingPluginsManifest.UserPluginsproperty. This addition aligns with the PR objectives.
363-363: Added new API method for checking if a plugin has been modified.This method correctly implements the
PluginModifiedmethod declared in theIPublicAPIinterface by delegating to the existingPluginManager.PluginModifiedmethod. This addition aligns with the PR objectives.
365-366: Added new API method for updating plugins.This method correctly implements the
UpdatePluginAsyncmethod declared in theIPublicAPIinterface by delegating to the existingPluginManager.UpdatePluginAsyncmethod. This addition aligns with the PR objectives.
368-369: Added new API method for installing plugins.This method correctly implements the
InstallPluginmethod declared in theIPublicAPIinterface by delegating to the existingPluginManager.InstallPluginmethod. This addition aligns with the PR objectives.
371-372: Added new API method for uninstalling plugins.This method correctly implements the
UninstallPluginAsyncmethod declared in theIPublicAPIinterface by delegating to the existingPluginManager.UninstallPluginAsyncmethod. This addition aligns with the PR objectives.Flow.Launcher.Plugin/Interfaces/IPublicAPI.cs (6)
348-356: Added well-documented API method for updating plugin manifest.This method declaration includes comprehensive XML documentation that clearly explains its purpose, parameters, and return value. It properly specifies default parameter values and return type.
358-362: Added well-documented API method for retrieving plugin manifest.This method declaration includes clear XML documentation that explains its purpose and return value. The return type
IReadOnlyList<UserPlugin>is appropriate as it provides read-only access to the plugin list.
364-371: Added well-documented API method for checking plugin modifications.This method declaration includes comprehensive XML documentation that clearly explains its purpose, the meaning of the
idparameter, and when a plugin is considered modified. The documentation helps users understand the implications of plugin modifications.
373-383: Added well-documented API method for updating plugins.This method declaration includes detailed XML documentation that clearly explains its purpose, parameters, and behavior regarding zip file handling. The documentation is thorough and helps users understand how the plugin update process works.
385-393: Added well-documented API method for installing plugins.This method declaration includes comprehensive XML documentation that clearly explains its purpose, parameters, and behavior regarding zip file handling. The documentation is consistent with the update method documentation.
395-403: Added well-documented API method for uninstalling plugins.This method declaration includes thorough XML documentation that clearly explains its purpose, parameters, and the optional behavior of removing plugin settings. The documentation helps users understand the implications of plugin uninstallation.
Flow.Launcher/SettingPages/ViewModels/SettingsPanePluginStoreViewModel.cs (2)
15-21: Using the new API abstraction looks good!This refactoring improves the code's architecture by accessing the plugin manifest through the API layer (
App.API.GetPluginManifest()) instead of directly accessingPluginsManifest.UserPlugins. This change promotes better separation of concerns and increases maintainability.
26-26:❓ Verification inconclusive
API usage improvement looks good, but consider parameter usage
The change to use
App.API.UpdatePluginManifestAsync()instead of the direct manifest call is a good architectural improvement.However, according to the PR description, this method accepts a
usePrimaryUrlOnlyparameter, which isn't being utilized here. Consider whether you should be passing a specific value for this parameter based on your use case.
🏁 Script executed:
#!/bin/bash # Check the signature of the UpdatePluginManifestAsync method to confirm parameter usage rg -A 3 "UpdatePluginManifestAsync" --type csLength of output: 2520
Consider Explicitly Passing the
usePrimaryUrlOnlyParameterThe architectural improvement is solid. However, note that the
UpdatePluginManifestAsyncmethod accepts ausePrimaryUrlOnlyparameter (defaulting tofalse), and here it’s being invoked without an explicit value. Please verify whether relying on the default (false) is intentional or if a specific value should be provided based on the intended behavior—especially since elsewhere (e.g., in PluginsManager) the parameter is explicitly passed.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.
See ❌ Event descriptions for more information. If the flagged items are 🤯 false positivesIf items relate to a ...
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
Flow.Launcher.Plugin/UserPlugin.cs (6)
35-38: Fix reference to non-existent AllowedLanguage class in XML documentation.The XML documentation for the
Languageproperty references a classAllowedLanguageusing the<see cref="AllowedLanguage"/>tag, but this class doesn't appear to be defined in the given code or context. Either include the definition ofAllowedLanguageor update the documentation to correctly describe the expected values./// <summary> -/// Allow language of the plugin <see cref="AllowedLanguage"/> +/// Language of the plugin (e.g., "csharp", "python", etc.) /// </summary> public string Language { get; set; }
8-9: Consider using init-only properties with record for better immutability.Records in C# are typically used to model immutable data. Currently, all properties have public setters, making them mutable. Consider using init-only properties to enforce immutability, which aligns better with the record concept and could prevent accidental modifications after initialization.
public record UserPlugin { /// <summary> /// Unique identifier of the plugin /// </summary> - public string ID { get; set; } + public string ID { get; init; } // Apply similar changes to other properties }
30-33: Use System.Version for better version handling.Using a plain string for versions doesn't provide validation or comparison capabilities. Consider using
System.Versionwhich provides built-in parsing, validation, and comparison functionality for version strings./// <summary> /// Version of the plugin /// </summary> -public string Version { get; set; } +public Version Version { get; set; }This would require version strings to follow semantic versioning format but provides better type safety and comparison capabilities.
13-13: Consider non-nullability for essential properties.Essential properties like
IDshould never be null. Consider using non-nullable reference types (with#nullable enable) or adding validation to ensure critical properties are not null./// <summary> /// Unique identifier of the plugin /// </summary> -public string ID { get; set; } +public string ID { get; set; } = string.Empty;Alternatively, if using C# 8.0 or later:
#nullable enable public string ID { get; set; } = null!;
1-4: Consider adding appropriate using directives for serialization.Based on the provided code snippet from
GetPluginInfoFromZip, this class is deserialized from JSON. Consider adding the appropriate System.Text.Json attributes to control serialization/deserialization behavior.using System; +using System.Text.Json.Serialization; namespace Flow.Launcher.PluginThen you can add attributes to properties if needed:
[JsonPropertyName("id")] public string ID { get; set; }
13-73: Add validation for required properties.There's no validation to ensure required properties are properly set. Consider implementing a validation method or constructor that validates essential properties.
public record UserPlugin { // Properties... /// <summary> /// Validates that all required properties are set /// </summary> /// <exception cref="InvalidOperationException">Thrown when a required property is missing</exception> public void Validate() { if (string.IsNullOrEmpty(ID)) throw new InvalidOperationException("Plugin ID is required"); if (string.IsNullOrEmpty(Name)) throw new InvalidOperationException("Plugin Name is required"); // Add validation for other required properties } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Flow.Launcher.Plugin/UserPlugin.cs(1 hunks)
🧰 Additional context used
🧬 Code Definitions (1)
Flow.Launcher.Plugin/UserPlugin.cs (1)
Plugins/Flow.Launcher.Plugin.PluginsManager/Utilities.cs (1)
UserPlugin(62-80)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
- GitHub Check: gitStream.cm
| @@ -1,5 +1,6 @@ | |||
| using Flow.Launcher.Infrastructure.Http; | |||
| using Flow.Launcher.Infrastructure.Logger; | |||
| using Flow.Launcher.Plugin; | |||
There was a problem hiding this comment.
Needed?
Record class UserPlugin is moved to Flow.Launcher.Plugin, so we need to use this namespace here
| using System.Linq; | ||
| using System.Threading; | ||
| using System.Threading.Tasks; | ||
| using Flow.Launcher.Plugin; |
There was a problem hiding this comment.
Needed?
Record class UserPlugin is moved to Flow.Launcher.Plugin, so we need to use this namespace here
| /// Update the plugin manifest | ||
| /// </summary> | ||
| /// <param name="usePrimaryUrlOnly"> | ||
| /// FL has multiple urls to download the plugin manifest. Set this to true to only use the primary url. |
There was a problem hiding this comment.
Have we added support for multiple manifest urls or are they just mirrors?
| @@ -1,5 +1,4 @@ | |||
| using Flow.Launcher.Core.ExternalPlugins; | |||
| using ICSharpCode.SharpZipLib.Zip; | |||
| using ICSharpCode.SharpZipLib.Zip; | |||
There was a problem hiding this comment.
We use ZipInputStream and ZipEntry in function Unzip, so we need to use this namespace.
| </ItemGroup> | ||
|
|
||
| <ItemGroup> | ||
| <PackageReference Include="SharpZipLib" Version="1.4.2" /> |
There was a problem hiding this comment.
I don't think this is used right?
Previous version also refers to this package as transitive package from Flow.Launcher.Core project becausesquirrel.windows package use SharpZipLib package. Since this PR drops project reference of Flow.Launcher.Core project, we need to add this package reference.
2 participants
New API functions
Add api functions from
PluginManifestandPluginManager. This can help PluginManager drop reference to FL project and also make third-party plugin manager plugin possible.