spago
spago copied to clipboard
purescript
Add --offline flag
Description of the change
Fixes #575
Checklist:
- [x] Added the change to the "Unreleased" section of the changelog
- [ ] Added some example of the new feature to the
README - [x] Added a test for the contribution (if applicable)
P.S.: the above checks are not compulsory to get a change merged, so you may skip them. However, taking care of them will result in less work for the maintainers and will be much appreciated 😊
I'm not really sure what should be added to the readme (if anything). It's more likely that Nix tools would update their readme to show how to use this command in their workflow.
I think we could merge this already, but I'd first like that we figure out a good testing story for this, because if we can't properly test that the changes we introduce are going to continue working, then we are deemed to break them.
I don't have many ideas about this though - nix-shell doesn't seem to offer any switch to disable the network :thinking:
Could you mock all network calls so they fail the test right away if called? You could use these mocked calls for the offline mode test only.
Oh, it looks like we can call a process with unshare -r -n to prevent it from reaching the network (on linux at least. We can run the offline tests only on Linux, I'm fine with this)
So I'd say the next step on this is to fixup a test infrastructure that runs the tests for the offline feature in such wrapper
Hmm... I should add a second test that verifies spago build fails when we drop the offline flag but still use unshare -r -n...
Dropping the offline flag but still running unshare -r -n does not produce the expected failure. I wondered as much. AFAICT, spago build should always work so long as the dependencies are stored in the cache folder. I think the real issue is that running Spago in a Nix environment means the .cache folder doesn't contain these dependencies and so triggers the network call.
@JordanMartinez I see. The location of both Dhall and Spago folders is dependent on the value of the XDG_CACHE_DIR environment variable. We could try to set that do a temp directory when running these tests, so that they would start from a clean slate?