[repo-assist] Fix find-packages failing on ~ home-directory local NuGet feed paths - #4427
Draft
github-actions[bot] wants to merge 1 commit into
Draft
Conversation
…4243) Dependencies.FindPackagesByNameAsync (used by the find-packages CLI command) passed the raw local source path directly to Fake.Globbing.search without normalizing it, unlike NuGet.fs/NuGetLocal.fs which already call Utils.normalizeLocalPath. This caused a DirectoryNotFoundException when a local source used '~/...' shorthand, since '~' was not expanded to the user's home directory. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 This is an automated response from Repo Assist.
Closes #4243
Root cause
Dependencies.FindPackagesByNameAsyncinsrc/Paket.Core/PublicAPI.fs(used by thepaket find-packagesCLI command) handled theLocalNuGet(s,_)case by passing the raw source pathsdirectly toFake.Globbing.search, without normalizing it first.Other local-feed code paths (
NuGet.fs,NuGetLocal.fs) already callUtils.normalizeLocalPathbefore resolving a local feed directory, which expands a~/home-directory shorthand and resolves relative paths correctly.FindPackagesByNameAsyncwas missing this step, so a source like~/nugetwas searched literally as<cwd>/~/nuget, producing the reportedDirectoryNotFoundException.Fix
Added a call to
Utils.normalizeLocalPathon the local source path inFindPackagesByNameAsync, extracting the resolved string from the returnedAbsolutePath/RelativePathcase before passing it toFake.Globbing.search. This matches the pattern already used elsewhere in the codebase.Trade-offs
FindPackagesByNameAsync.Path.IsPathRootedalready treats as rooted) are unaffected, sincenormalizeLocalPathreturns them unchanged as an absolute path.Test Status
dotnet build src/Paket.Core/Paket.Core.fsproj -c Debug -f netstandard2.0— succeeded, no new warnings/errors.FindPackagesByName expands home directory (~) for local NuGet feedintests/Paket.Tests/UtilsSpecs.fs, which creates a real temp folder under the user's home directory containing a minimal valid.nupkg, and verifiesDependencies.FindPackagesByNamelocates it via a~/...source. Ran withdotnet test tests/Paket.Tests/Paket.Tests.fsproj --filter "FullyQualifiedName~FindPackagesByName" -f net10.0— Passed (1/1).UtilsSpecssuite in this PR; a prior run of the broader filter showed 4 pre-existing, unrelated failures inhttp_proxy/https_proxyenvironment-variable tests that are not affected by this change.Add this agentic workflow to your repo
To install this agentic workflow, run