'No entry found' error while resolving git package, but path is valid

[avius-diomedes]

Update: Issue seems to be related to some kind of cache. I was able to fix the issue by deleting C:\Users\...\.pesde\data and re-running pesde self-install.

While running pesde install with the following dependency in pesde.toml

the following error occurs:

Rust back-trace:

However, it works just fine if using the commit SHA or rev="v0.1.0" like so:

This is the structure of the repository. It is a mono-repo with several pesde packages in it, one of them being alarm_light.

Git shows that the path exists in the tree under main.

Both v0.1.0 and main point to the same revision.

I'm not entirely sure if the issue actually has to do with pesde, but I assume so since the entry exists but pesde install errors as if it doesn't.

[daimond113]

Is there any chance you had changed the default branch from the time when the repository was first cloned? As far as I know, we're only able to resolve the default branch - others require commit hashes/tags (I might be wrong with this, though). Also, does that folder have a pesde.toml? It is required to use the path as a dependency.

[avius-diomedes]

Thanks for your response!

I don't believe the default branch has changed since the repo was cloned. The repo was initialized in GitHub and cloned with default branch main. The repository has no other branches. Also, roblox/alarm_light/ and all other directories inside roblox/ have pesde.toml and are valid pesde packages.

Does pesde cache Git repositories? If so, I believe the cause of the issue might be there:

• This problem seems to only happen with packages have been pushed to the mono-repo recently. Packages that were pushed a while ago seem to install just fine.
• There was another similar case where the dependency downloaded but failed due to Luau parsing error (expected.) After fixing the typo and pushing the commit, the dependency continued to error during install until I deleted data and re-installed pesde.
• In both cases, I found that deleting ~\.pesde\data\ and then running pesde self-install seemed to fix the issue, at least temporarily

These three things seem indicative of an out-of-date cache that isn't getting refreshed properly, but I'm not too familiar with the entire codebase so I'm not entirely sure.

[daimond113]

pesde doesn't cache repositories so to say, it only maintains a (bare) clone that should be updated to the latest state of the remote repository when it is being used, for example during resolving. That means the repository should always be refreshed (using the logic here) in your case, since it won't write a lockfile if it errored meaning it has to resolve the graph fresh. I haven't had any issues with the refreshing logic in the past, but there could be something I'm missing so I've linked the code responsible for it if you're willing to take a look. Otherwise, I'm not sure about the cause of the issue.

About your fix, if you delete ~/.pesde/data but don't run self-install does the issue persist? I don't see any part of the self-install process which could affect Git dependencies.

[avius-diomedes]

Good to know. Thanks for the link; I'll definitely look at the code.

As for the solution, it's entirely possible that self-install isn't required. I only did that to make sure that the pesde installation was at its intended initial state without the cache. Next time the issue happens, I'll try it without doing self-install and see if it still works.