-
Notifications
You must be signed in to change notification settings - Fork 2
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
FR (Versioning): Improve NuGet Version Range Support #50
Comments
Improving the NuGet Version Range handling should also help with 2 other problems:
|
To make this work this would require a change to all of the versioning and version control logic. Thankfully, we could likely get away with using $bootstrapper.GetAllVersions() to help with most of it. Figuring out which packages are in range she probably be done by Resolve-CachedPackage. However, something clever will have to be done about determining the range overlap.
|
I think a starting point would be to add a field to PackageData that caches a call to GetAllVersions(). In theory, this would do 2 things:
This could also allow for a lot more advanced version control logic, since PackageData is currently limited to GetStable() and GetPrerelease() |
This would likely warrant recursion when selecting dependencies for the best range of a package. To optimize looping, I think the best option is to only recurse when the upper bounds of a range has changed. |
The upper and lower bounds should include 3 versions:
|
Another problem that would warrant a complete refactor is that currently due to Import-Package's simplistic version control, Import-Package is able to load dependencies at the same time that it builds the dependency tree. While I might be able to keep this design in mind:
I think it might be best to separate loading and tree parsing into 2 separate steps. This would slow Import-Package down, but would allow me to add more features down the road. |
An optimization that could help with dependency loading is using the v3-flatcontainer API to download just the nuspec, instead of the entire .nupkg when parsing the dependency tree. EDIT: PartialZip is available in C# and could be transpiled to PowerShell (or installed during the bootstrapper process)
|
Example implementation:
|
Adding such support would also likely warrant refactoring any filesystem modifications done by Resolve-CachedPackages, as the current design would cause a performance hit any time the ranges are updated, if this change is implemented. |
It doesn't look like NuGet supports byte ranges. It also looks like they don't have an API for exposing the content of the .nupkgs: |
Feature implementation started. See: pwsh-cs-tools/Import-Package@28550db |
Should fix the following comment from #49:
- #49 (comment)
Part of the issue is that Azure.Monitor.OpenTelemetry.Explorer is likely using an older version, and that the Bootstrapper is detecting an unbounded version range (which is currently not supported).
However, a bit of work has been already done to improve Import-Package's versioning control when the -CachePath parameter was introduced, so logic to compare semantic versions may already be available.
The text was updated successfully, but these errors were encountered: