Skip to content

[repo-assist] Fix find-packages failing on ~ home-directory local NuGet feed paths - #4427

Draft
github-actions[bot] wants to merge 1 commit into
masterfrom
repo-assist/fix-issue-4243-tilde-path-80eabfca02a6066a
Draft

[repo-assist] Fix find-packages failing on ~ home-directory local NuGet feed paths#4427
github-actions[bot] wants to merge 1 commit into
masterfrom
repo-assist/fix-issue-4243-tilde-path-80eabfca02a6066a

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

🤖 This is an automated response from Repo Assist.

Closes #4243

Root cause

Dependencies.FindPackagesByNameAsync in src/Paket.Core/PublicAPI.fs (used by the paket find-packages CLI command) handled the LocalNuGet(s,_) case by passing the raw source path s directly to Fake.Globbing.search, without normalizing it first.

Other local-feed code paths (NuGet.fs, NuGetLocal.fs) already call Utils.normalizeLocalPath before resolving a local feed directory, which expands a ~/ home-directory shorthand and resolves relative paths correctly. FindPackagesByNameAsync was missing this step, so a source like ~/nuget was searched literally as <cwd>/~/nuget, producing the reported DirectoryNotFoundException.

Fix

Added a call to Utils.normalizeLocalPath on the local source path in FindPackagesByNameAsync, extracting the resolved string from the returned AbsolutePath/RelativePath case before passing it to Fake.Globbing.search. This matches the pattern already used elsewhere in the codebase.

Trade-offs

  • Minimal, surgical change limited to the local-NuGet-feed branch of FindPackagesByNameAsync.
  • Genuinely rooted paths (including UNC paths, which Path.IsPathRooted already treats as rooted) are unaffected, since normalizeLocalPath returns 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.
  • Added a new regression test FindPackagesByName expands home directory (~) for local NuGet feed in tests/Paket.Tests/UtilsSpecs.fs, which creates a real temp folder under the user's home directory containing a minimal valid .nupkg, and verifies Dependencies.FindPackagesByName locates it via a ~/... source. Ran with dotnet test tests/Paket.Tests/Paket.Tests.fsproj --filter "FullyQualifiedName~FindPackagesByName" -f net10.0Passed (1/1).
  • Did not run the full UtilsSpecs suite in this PR; a prior run of the broader filter showed 4 pre-existing, unrelated failures in http_proxy/https_proxy environment-variable tests that are not affected by this change.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
Comment /repo-assist to run again

Add this agentic workflow to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@ae8d551f07c7ed7619f8c58c7bb4c3ac89395d38

…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

find-packages command fails when using UNC paths

0 participants