Support subdirectory projects other than `test`

[ReubenJ]

I'm setting up benchmarks for a package, and I'm using some benchmark-only dependencies. The setup is the same as the test setup supported by TestEnv, with test-only dependencies in test/Project.toml. I'd like to be able to activate an environment from benchmark/Project.toml with the current package under development layered on top.

I think this is as simple as adding a keyword argument to activate to specify which subdirectory to target. Currently, the subdirectory is hardcoded to "test":

TestEnv.jl/src/julia-1.13/activate_do.jl

Line 17 in 7a0f833

return sandbox(ctx, pkgspec, joinpath(path, "test"), test_project_override; allow_reresolve) do

TestEnv.jl/src/julia-1.13/activate_set.jl

Line 14 in 7a0f833

sandbox_path = joinpath(pkgspec.path::String, "test")

TestEnv.jl/src/julia-1.13/activate_set.jl

Line 66 in 7a0f833

base_path = test_dir_has_project_file(temp_ctx, pkgspec) ? joinpath(pkgspec.path, "test") : pkgspec.path

Adding a keyword argument to activate, such as subdir, should be enough to support this functionality without introducing any breaking changes, so long as it defaults to "test". I gave this a try (be9279a), and it seems to work as I'd expect.

A couple of questions:

• Is this within the scope of TestEnv?
• Is the change above enough to support the functionality I'm describing?

[ReubenJ]

Upon further reading, it looks like [workspaces] in Pkg are more or less already handling this setup (or changing the pattern so that the dev'd package is explicitly included), so maybe this change isn't necessary.

[oxinabox]

Yes, if you are using workspaces with seperate Project.tomls in each folder then the workspaces feature handles this natively.
TestEnv is mostly useful for if you have a test env but are not using the workspaces feature.