-
Notifications
You must be signed in to change notification settings - Fork 904
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
(#508) Attempt to resolve relative paths for sources #2943
Conversation
418f3a3
to
0379cdf
Compare
choco/src/chocolatey.tests.integration/scenarios/InfoScenarios.cs Lines 89 to 97 in 0379cdf
This test is failing, and I'm not quite sure why. Comparing the actual output vs the expected output, they appear to be the same. |
48380e8
to
a8242f3
Compare
I've tweaked the info output to make it the same as it was with NuGet.Core, so as to make the integration test pass. |
a8242f3
to
7f8a769
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.
LGTM!
@TheCakeIsNaOH the unit tests seem to be failing on Posix. Is this something that you can take a look at? |
When setting up NuGet sources, if NuGet is unable to parse the path, this tries to resolve relative paths to absolute, and then retries setting up the NuGet source. If the path is unable to be resolved, then this ignores the error and lets NuGet handle the resulting invalid source. This path resolution requires the filesystem to be passed in. This means that various method signatures change to allow access to the filesystem. When using NuGet.Core, then relative paths were able to be resolved. But now with NuGet.Client, relative paths are resolved by clients, not by libraries, which is why this change has to be made. NuGet/NuGet.Client#3783
This adds tests to ensure that NuGet is able to parse various types of NuGet sources correctly. This includes http, https, and local paths, where local paths include absolute, different types of relative paths, and UNC.
e4e88ed
to
1988b90
Compare
This makes the info output the same as it was when using NuGet.Core so as to keep the info output the same as it is with v1.x
1988b90
to
0e7b369
Compare
@gep13 I've updated this, and it is ready for review again. |
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.
LGTM!
@TheCakeIsNaOH thanks for getting this updated! |
Description Of Changes
When setting up NuGet sources, if NuGet is unable to parse the path, this tries to resolve relative paths to absolute, and then retries setting up the NuGet source. If the path is unable to be resolved, then this ignores the error and lets NuGet handle the resulting invalid source.
This path resolution requires the filesystem to be passed in. This means that various method signatures change to allow access to the filesystem.
Motivation and Context
When using NuGet.Core, then relative paths were able to be resolved. But now with NuGet.Client, relative paths are resolved by clients, not by libraries, which is why this change has to be made. NuGet/NuGet.Client#3783
Testing
.nupkg
toC:\packages
C:\
choco.exe
from this PR with.\choco.exe info wget --source="C:\packages"
choco.exe
from this PR with.\choco.exe info wget --source="packages"
C:\packages
choco.exe
from this PR with.\choco.exe info wget --source="."
install
(with-n -f
) instead ofinfo
, and validate that the package installs each time.Operating Systems Testing
Change Types Made
Change Checklist
Related Issue
Part of #508