Interesting way of handling project vs global scope:
Some package managers (e.g. npm) use per-project scope by default, but also allow you to install packages globally using flags (npm install -g). Others (e.g. brew) use global scope.
I like the idea of allowing both project and global scope, but I do not like the flags approach. Why don't we apply a heuristic:
If there is a .sqlpkg folder in the current directory, use project scope.
Otherwise, use global scope.
This way, if users don't need separate project environments, they will just run sqlpkg as is and install packages in their home folder (e.g. ~/.sqlpkg). Otherwise, they'll create a separate .sqlpkg for each project (we can provide a helper init command for this).
Seems rather implicit, though, especially if the command output doesn't specify which scope a package was installed in. If a user moves to a subdirectory, forgets they are there, and then tries to install a package, the package will unexpectedly install in global scope (though this particular version of the problem can be solved by also looking in parent directories).
Interesting way of handling project vs global scope:
Seems rather implicit, though, especially if the command output doesn't specify which scope a package was installed in. If a user moves to a subdirectory, forgets they are there, and then tries to install a package, the package will unexpectedly install in global scope (though this particular version of the problem can be solved by also looking in parent directories).