Downgrade action doesn't work with test/Project.toml

[sethaxen]

In Julia <v1.13, one can add test dependencies using [extras] or in a test/Project.toml: https://pkgdocs.julialang.org/v1/creating-packages/#Test-specific-dependencies
In Julia v1.13, the [extras] approach is deprecated, and the recommended approach uses test/Project.toml with a test [workspace] and/or a [sources] entry, and with the package itself added as a test dependency. https://pkgdocs.julialang.org/dev/creating-packages/#Test-specific-dependencies

I've been moving my packages to a [workspace]-based workflow, but I haven't been able to figure out how to use this action with these packages. Here's a simple test package: https://github.com/sethaxen/DowngradeTestPackage.jl. It has two workflows. Both downgrade either just . or both . and test, and both either build . or build test before running tests.

Downgrade v1

Uses v1 of this action with various levels of strictness. See https://github.com/sethaxen/DowngradeTestPackage.jl/actions/runs/20269280645 for example results. To summarize the results, if we downgrade .,test and build ., then we succeed in downgrading test dependencies for all Julia versions and levels of strictness.

Downgrade v2

Uses the main branch of this action with various modes. See https://github.com/sethaxen/DowngradeTestPackage.jl/actions/runs/20269280613 for example results. There's no combination of arguments that succeeds in downgrading the test dependencies. If we try to downgrade test, then we get the error: unknown package UUID: 598b003f-0677-49cf-8d2a-39b1658b755a, which is the UUID of the package itself.

Presumably this happens because the package is not registered, but I've seen this happen also for registered packages when the compat bound for the package in test/Project.toml doesn't match a previous release of the package (e.g. v0.2.0 is released, the test/Project.toml has a compat bound of unreleased v0.3).

Yet another issue, which I can only recreate for a registered package, is that when the downgrade action is run on test, it installs in the package manifest an old release of the package instead of the local version. One can't even resolve the environment then, because Pkg expects the package manifest to contain the package itself.

[JoshuaLampert]

If I understand correctly, this is related to the issue (or the same?) I noticed here: trixi-framework/Trixi.jl#2674 (comment), i.e., v2 of the downgrade action does not resolve the test Project.toml and the main Project.toml simultaneously as it is done when running tests, but independently. This can be seen by looking at the code:

julia-downgrade-compat/downgrade.jl

Line 168 in c74e2c0

for dir in dirs

It just loops through the dirs and runs Resolver.jl for each of the projects, but it should merge "." and "test" and only run Resolver.jl for the merged project.

cc @ChrisRackauckas @ranocha

[ChrisRackauckas-Claude]

I've submitted a fix in #37 that addresses the local [sources] issue by:

1. Detecting packages with local path sources (e.g., [sources.PackageName] with path="..")
2. Temporarily removing them from [deps], [compat], [extras], and [sources] before running Resolver.jl
3. Restoring the original Project.toml after resolution

This allows test dependencies like Compat to be properly minimized while excluding the main package (which is sourced locally) from registry resolution.

Note: There's a separate issue in Resolver.jl when handling workspace projects with Julia 1.9+ extension handling that causes an MbedTLS_jll error in fixups_from_projectfile!. This is unrelated to the local sources issue and would need to be addressed in Resolver.jl itself.