spago
spago copied to clipboard
purescript
Build new package when installed
spago install package-name
Doesn't seem to build a newly downloaded package.
So have to do after:
spago build [--deps-only]
Though it is not very convenient as it rebuilds all the sources, at least what I see.
I agree that building a package after installing it could be convenient, but what we always meant by "install" in Spago is "download locally". For building packages we only used the "build" verb.
I wonder what's the usecase for this?
About rebuilding all sources: Spago does not decide which sources need to be built, we pass all the globs to the compiler and the compiler decides what to build.
Ok, I checked now that without vscode running in the same directory after installing a new package and running spago build it builds only new dependencies.
So is probably the known issue with vscode watching you were talking about. I believe it refers then to https://github.com/purescript/purescript repo? But I don't see the issue there. And I just wonder how does it really mess with vscode watcher, any ideas for this?
I cannot find the relevant issue in the purescript repo unfortunately. I can only say that so far the recommended workflow is spago install package-name and spago build --deps-only. I'm open to change/improve this, but we'd need to figure out a better UX (if any) first
Well the UX good would be spago install package-name --build or if decide that it should build by default, then spago install package-name --no-build. And spago could send to purs.bin only globs related to newly installed packages (I'm more with the later option).
But I'm more concerned about this with total rebuilding bug, I will look into what really causes it, will open an issue PS repo.
I'm interested in working on this; I'm just wondering what UX we're going with. Will it be @wclr's --build suggestion? I don't mind waiting until there's a consensus.
On the one hand, things should be explicit, so the --build option would be preferred.
But from the use case perspective, when a user installs a package in 99% percent of cases one would want it to be compiled and available to the code, this speaks for --no-build option which is used when a use case is specific.
Though probably it is better to start with --build option, as this is just a non-breaking anything addition, and could be changed in future easily if decided.
We are generally fine with breaking changes, that's not really the issue here. The reason why I have doubts about this is that we'd change the general meaning of the CLI commands. So far it has been that
installdownloads packages, eventually adding them to your configbuildinvokes the compiler, eventually callinginstallif the packages are missing
You are proposing that we change it to:
installdownloads and builds packages, eventually adding them to your configbuildinvokes the compiler, eventually callinginstallif the packages are missing
Do you see the circular dependency? How should we untangle it?
Maybe we should separate spago install (renaming it to spago fetch) from spago install package-name.
In this way it would make sense that fetch does a different thing than install, which would also build the packages when adding them to the config. We'd have to rename a few flags along the way too, e.g. --no-install could become --no-fetch.
How does this sound?
Maybe we should separate spago install (renaming it to spago fetch)
What are the real use cases for using fetch vs installing and building the package?
I can think of one: to check if the package exists, download and check if it would conflict with the codebase, but that would require kind of build, but at least it is the real and useful use case.
What are the real use cases for using
fetchvs installing and building the package?
People often want separate commands to just download the packages (which requires network) vs building them (which doesn't require network).
I often use spago install to cache entire package sets if I know I'm going to be without network, and I've used and seen it used as a separate step in CI for separation of concerns.
Note: spago install does a different thing than spago install somepackage, which is why I'm proposing that we rename it to spago fetch