Skip to content

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

Open
github-actions[bot] wants to merge 3 commits into
masterfrom
repo-assist/fix-issue-4243-tilde-path-80eabfca02a6066a
Open

github-actions[bot] wants to merge 3 commits 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.0 — Passed (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>
@dsyme
dsyme marked this pull request as ready for review September 27, 2026 16:28

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

1 participant