In monorepos, allow running commands from package directories

[roryc89]

In a monorepo it would more convenient to allow some commands (build, install, uninstall, run, test, bundle) to be run from the package, instead of having to run them from the workspace directory with the package flag.

As our project is very large, I often work on individual packages as the IDE is slow when working on the whole workspace. It is then a bit cumbersome to have to change directory and add the package flag in order to run any spago commands on the package.

Currently to install a dependency when working in a monorepo the commands look something like this:

cd ../..
spago install -p lib-components some-dep
cd lib/components

ideally I would just like to run:

spago install some-dep

[f-f]

I have wished for this before, and we don't have it yet because of UX concerns - I couldn't find a satisfactory answer to "what happens when there's no workspace in the current folder".

That is, Spago will need workspace info for all the commands you mentioned (since it has to find the monorepo output folder, the lockfile, possibly resolve a build plan, etc).
Would we start looking up into parent directories? Is there a stopping point for how high to climb? Do we traverse links? (which might lead to loops). And what if there's no workspace in any parent folder? (Stack has a "default project" in the user's home folder, that is used when this happens. Not sure I'm a fan of that)

[roryc89]

I think having a low max height to search would be reasonable (8?), perhaps with the option to increase it in the package config.

If there's no workspace found, throw an informative error.

This might not be perfect but I think it would be an improvement on the current UX in these situations.

I agree that I wouldn't follow Stack's default project in home folder setup.

[f-f]

I think having a low max height to search would be reasonable (8?), perhaps with the option to increase it in the package config.
If there's no workspace found, throw an informative error.

Let's try this out, but keep it at 4 levels of directories (following symlinks), and with no additional configuration - if someone needs more than that we can discuss bumping up the limit, but the priority is to keep the amount of available configuration knobs as low as possible.

[peterbecich]

Is there a stopping point for how high to climb?

How about .git as the stopping point?

Emacs projectile does it this way:
https://docs.projectile.mx/projectile/projects.html

Broadly speaking, Projectile identifies projects like this:

• Directories that contain the special .projectile file
• Directories under version control (e.g. a Git repo)
• Directories that contain some project description file (e.g. a Gemfile for Ruby projects or pom.xml for Java maven-based projects)

obviously point 3 is not helpful

[peterbecich]

Looking here

spago/src/Spago/Config.purs

Lines 183 to 200 in f130b33

	-- First try to read the config in the root. It _has_ to contain a workspace
	-- configuration, or we fail early.
	{ workspace, package: maybePackage, workspaceDoc } <- readConfig "spago.yaml" >>= case _ of
	Left errLines ->
	die
	[ toDoc "Couldn't parse Spago config, error:"
	, Log.break
	, indent $ toDoc errLines
	, Log.break
	, toDoc "The configuration file help can be found here https://github.com/purescript/spago#the-configuration-file"
	]
	Right { yaml: { workspace: Nothing } } -> die
	[ "Your spago.yaml doesn't contain a workspace section."
	, "See the relevant documentation here: https://github.com/purescript/spago#the-workspace"
	]
	Right config@{ yaml: { workspace: Just workspace, package }, doc } -> do
	doMigrateConfig "spago.yaml" config
	pure { workspace, package, workspaceDoc: doc }

spago/src/Spago/Config.purs

Lines 202 to 210 in f130b33

	logDebug "Gathering all the spago configs in the tree..."
	otherConfigPaths <- liftAff $ Glob.gitignoringGlob Paths.cwd [ "**/spago.yaml" ]
	unless (Array.null otherConfigPaths) do
	logDebug $ [ toDoc "Found packages at these paths:", Log.indent $ Log.lines (map toDoc otherConfigPaths) ]
	-- We read all of them in, and only read the package section, if any.
	let
	readWorkspaceConfig :: FilePath -> Spago (Registry.RegistryEnv _) (Either Docc ReadWorkspaceConfigResult)
	readWorkspaceConfig path = do

I would be happy to attempt to complete this issue, please assign to me

[f-f]

@peterbecich thanks! Assigned - and these are good pointers. In there you'd see if there's a workspace in the current directory, and start recursing up if not, instead of calling die in the Left branch. Then you'd eventually figure out the right cwd (i.e. the rootDir of the project), and pass it to the globbing code in line 203.

The issue is a little thorny, since Spago does depend on the cwd being consistently at the root. I am afraid that this will turn out into having to thread the rootDir throughout the code, which could be very annoying.
Hopefully we can stash it in the various environments and adjust all the paths with that.
Feel free to ping me if you have questions or if you'd like to talk through the patch as you build it.

[peterbecich]

Please review #1253
It handles the cwd being somewhere down the file tree from the root of the .git project.
It will go up to 4 levels up the tree, and look for any parent directory spago.yaml with workspace.
It does not search for "cousin" spago.yaml on the tree.