Using non-default resolution temporarily

[mosuem]

When using a multi-repo approach and the new workspace concept, is it possible to easily test with locally resolved packages as well as published ones? It might make sense to want to know if a package works locally while developing, but then also checking if it still works with the published versions of the dependencies, as there is no multi-package-atomic publishing.
Currently, the workaround is running a tool to comment out lines with path: and instead using published versions, which is very hacky and leads to less adoption of testing this in the ecosystem.

[sigurdm]

I think we want to be able to tell a story here eventually.

For now I think the recommendation will be that to test a package's resolution in isolation you should manually take it out of the workspace (by updating the pubspec.yaml to remove the resolution: workspace line), resolve (downgrade, upgrade or whatever) and run tests.

This is not ideal, as it

• requires manual/scripted editing of pubspec.yaml
• leaves the workspace in a messy state.

But it is not that hard to set up. And with git it is not hard to restore back to the working state.

Note with workspaces the packages inside the workspace will always resolve to each other.

You don't need to bother with overrides/path dependencies, and when you take it out of the workspace it will resolve to the hosted version of the dependency.

Leaving this issue open for picking it up eventually.

[sigurdm]

Related to #4127

[sigurdm]

Renamed this issue, because I think that is what we really need.

One way forward would be to have:

• dart test dart run etc. could take a --packages flag pointing to a non-default location.
• dart pub get could have a way to generate .dart_tool/package_config.json and pubspec.lock into a non-default location.