Get local development server to work again
JordanMartinez opened this issue · 9 comments
Currently, following the instructions here do not work. Further exploration has revealed that things break in this line, which matches the same code used in the REPL command.
While this is related to #183 and #219 in that we need to update the instructions, this issue is specifically about figuring out why the server can't start.
Here's what I've tried doing. To sum the below comment, I tried updating the dependencies (didn't work) and I noticed that the server starts if the spago.dhall file is configured such that prelude is the only dependency and the src/**/*.purs glob is removed.
I've tried updating the stack.yaml and trypurescript.cabal files to use more recent versions of the libraries. trypurescript's master branch is still relying upon lts-13.26 while purescript v0.14.1 is relying on lts-17.6. This attempt did not bear any fruit. Perhaps I did something wrong due to my unfamiliarity with Haskell, but I don't think that's it.
I also ran the following to see which modules were reported as not being found:
cd staging
stack exec trypurescript 8081 $(spago sources) | grep -Eo '\.spago\/[a-zA-Z0-9-]+\/'
I noticed that the output does not include .spago/prelude/. So one of two things are true. Either (1) Prelude is being handled correctly but other modules are failing for unknown reasons, or (2) Prelude isn't being included at all.
I have confirmed that (2) is false. If I remove all packages in the staging/spago.dhall file except for prelude, running stack exec trypurescript 8081 $(spago sources) will actually start the server (though it still produces the mangled output described in #216).
This implies that some other module is breaking things.
After doing the above (i.e. prelude is only dependency in spago.dhall and the src/**/*.purs glob was removed), I tried installing another package low in the ecosystem to see if running trypurescript would work.
- Installing
effectand then running the command failed. I thought perhaps this might be due to using FFI. I reverted my change. - Installing
newtypeand then running the command failed. This confirmed that packages with FFI aren't the cause of the problem.
I then created a new folder simple and wrote a small valid PureScript file that only uses Prelude things, and added a new source glob simple/**/*.purs to the spago.dhall file. Running the command started up the server and compiled the file.
Found the source of the issue.
In this test, I only have prelude and effect as my dependencies and don't have any source globs in spago.dhall. If I If I update Main.hs to print the module's full relative paths...
e <- runExceptT $ do
modules <- ExceptT $ I.loadAllModules inputFiles
+ liftIO $ traverse print $ fmap fst modules
(exts, env) <- ExceptT . I.runMake . I.make $ map (second CST.pureResult) modules
namesEnv <- fmap fst . runWriterT $ foldM P.externsEnv P.primEnv exts
pure (exts, namesEnv, env)it produced this output when I ran the command:
".spago/effect/v3.0.0/src/Effect/Class.purs"
".spago/effect/v3.0.0/src/Effect/Uncurried.purs"
".spago/effect/v3.0.0/src/Effect/Unsafe.purs"
".spago/prelude/v5.0.1/src/Control/Applicative.purs"
".spago/prelude/v5.0.1/src/Control/Apply.purs"
".spago/prelude/v5.0.1/src/Control/Bind.purs"
".spago/prelude/v5.0.1/src/Control/Category.purs"
".spago/prelude/v5.0.1/src/Control/Monad.purs"
".spago/prelude/v5.0.1/src/Control/Semigroupoid.purs"
".spago/prelude/v5.0.1/src/Data/BooleanAlgebra.purs"
".spago/prelude/v5.0.1/src/Data/Boolean.purs"
".spago/prelude/v5.0.1/src/Data/Bounded.purs"
".spago/prelude/v5.0.1/src/Data/CommutativeRing.purs"
".spago/prelude/v5.0.1/src/Data/DivisionRing.purs"
".spago/prelude/v5.0.1/src/Data/Eq.purs"
".spago/prelude/v5.0.1/src/Data/EuclideanRing.purs"
".spago/prelude/v5.0.1/src/Data/Field.purs"
".spago/prelude/v5.0.1/src/Data/Function.purs"
".spago/prelude/v5.0.1/src/Data/Functor.purs"
".spago/prelude/v5.0.1/src/Data/HeytingAlgebra.purs"
".spago/prelude/v5.0.1/src/Data/Monoid.purs"
".spago/prelude/v5.0.1/src/Data/NaturalTransformation.purs"
".spago/prelude/v5.0.1/src/Data/Ordering.purs"
".spago/prelude/v5.0.1/src/Data/Ord.purs"
".spago/prelude/v5.0.1/src/Data/Ring.purs"
".spago/prelude/v5.0.1/src/Data/Semigroup.purs"
".spago/prelude/v5.0.1/src/Data/Semiring.purs"
".spago/prelude/v5.0.1/src/Data/Show.purs"
".spago/prelude/v5.0.1/src/Data/Symbol.purs"
".spago/prelude/v5.0.1/src/Data/Unit.purs"
".spago/prelude/v5.0.1/src/Data/Void.purs"
".spago/prelude/v5.0.1/src/Record/Unsafe.purs"
".spago/prelude/v5.0.1/src/Type/Proxy.purs"
You'll notice a few issues:
".spago/effect/v3.0.0/src/Effect.purs"is never listed above, which is imported by the otherEffectfiles.".spago/prelude/v5.0.1/src/Prelude.purs"is never listed above.
This implies that top-level files in the source globs aren't being included for some reason. In other words, a source glob of directory/**/*.purs should pick up director/FileName.purs, but it isn't.
So, I edited the files in .spago/<packageName>/, such that they were no longer top-files (e.g. moving Prelude.purs into the Type folder). Rerunning the command started the server.
In short, there's a bug in the globs. I'm not sure how that needs to be fixed, but it's at least a better direction than what we had before.
Nice find! See if you can work out whether your shell is expanding the globs? I think if you can get the globs to not be expanded by the shell, they'll be expanded by purs instead, and that way it'll be more likely to work consistently across different environments.
Try set -o noglob if you're using Bash, for example.
Yup! That fixes it!
We need to run set -o noglob before running stack exec trypurescript $(spago sources)
Ha... Wish I would have realized the implication of this sooner