Run Spago from a nested directory other than workspace root

[fsoikin]

Description of the change

Fixes #1237
Allowing Spago to be launched from a directory nested within the workspace.

• When launched, Spago will walk directories up until it finds a spago.yaml containing a workspace.
• As it goes, it remembers config docs it finds and loads along the way.
  • We have to load them anyway in order to see if they contain a workspace. So we remember them in order to avoid loading them twice.
• After finding the root, it then globs for spago.yaml files back down the tree and loads those that it hasn't loaded while walking up.
  • The subprojects from down the tree are loaded in the order top-down, such that parent directories are traversed before their children.
  • If Spago encounters a config with a workspace, it remembers its path and does not attempt to load any configs nested under it.
  • If Spago encounters an unreadable config (e.g. malformed or with unknown fields), it will not attempt to load any configs nested under it.
• As it walks up the tree, it also gathers and remembers any spago.yml (wrong extension) files.
• As it walks up the tree, it also remembers the first spago.yaml it sees. If this is not the root project, it will become "selected".
  • I'm not 100% on this. Previous behavior has been to never "select" a project unless there is a -p option. But on the other hand, it's very likely that if your CWD is a particular project, you're probably working on just that one.
• If it goes all the way up to the file system root, it prints an error saying no config found and lists all the yml files found along the way, if any, suggesting that they may have the wrong extension.

Checklist:

• Added the change to the "Unreleased" section of the changelog
• [ ] Added some example of the new feature to the README
• Added a test for the contribution (if applicable)

[fsoikin]

All feedback addressed except the request to mention #951, because I didn't understand what it meant.

[peterbecich]

Thank you @fsoikin for implementing this feature!

[fsoikin]

This change and equivalent changes in other test fixtures are not related to the PR as such, but are fixing a different issue.

• Prelude 6.0.2 was published on February 15th. It is included in package set 63.3.0.
• Because of this, when building with registry solver, Spago pulls in this new version of prelude.
• These test projects, however, explicitly specify prelude 6.0.1 as well as package set versions that don't have prelude 6.0.2 in them.
• As a result, building with solver and building with package set produces different build plans, which in turn causes spago publish to run a new build, even if spago build was run immediately before it, which in turn produces compiler progress output, and this compiler progress output was unexpected in test fixtures, causing the tests to fail.
• To fix the issue, I upgraded the test fixtures to use prelude 6.0.2 and a corresponding package set, so that build plans with and without solver will match for these projects.
• This is not a good solution though, only a bandaid "for now". It will break again as soon as new packages are published. I'm not 100% sure what a good solution would be. Perhaps make the registry solver able to use a past snapshot of the registry? Or we could artificially cut out expected compiler output, like we already kind of do in some tests. Or, perhaps, this is actually good: this way Spago development never goes stale and keeps up with new stuff in new package sets.

[peterbecich]

@fsoikin , can this be merged as-is? When an updated package set causes test breakage in the future, I suggest we continue patching until a permanent solution is found. The value-add of this PR is already big, as it is. Thanks again

[f-f]

Sorry I got to this only now - thanks for the massive effort! ❤️

[peterbecich]

Yes, seconded, thank you @fsoikin.

@f-f , can we tag a new release 0.93.44 including this? I am trying to bring it into https://github.com/thomashoneyman/purescript-overlay

[f-f]

@peterbecich published 0.93.44

[peterbecich]

thanks @f-f !