-
Notifications
You must be signed in to change notification settings - Fork 20
Command to copy zipped sandbox to cabal's local sandbox #59
Comments
Currently, it’s not possible to copy the Halcyon sandbox to another location, because Cabal sandboxes are not relocatable (haskell/cabal#462, haskell/cabal#1490, haskell/cabal#1542, haskell/cabal#2302). However, all you need for
The possibility of doing so should be made clear in the documentation. This is now tracked as mietek/halcyon-website#2. Let me know if this helps. |
Will that sandbox be messed up if you run a different project? In that case I should just run (trying now) Ok I had to delete the /app/sandbox to get constraints to resolve (I just built Hoogle; my project is a Snap application), and now it has to rebuild the entire sandbox... oh well. I think I tried symlinking before but it felt wrong because the sandbox could be messed up by something else. Is making this simpler just a matter of improving cabal? |
Halcyon keeps a single sandbox only, suitable for the project for which you most recently ran Therefore, yes — if you want to build a different project, you should run For Halcyon to restore the sandbox (as opposed to rebuilding it), the sandbox must’ve already been built, archived, and uploaded to private storage — which is only possible if you’ve set up private storage first. Unfortunately, improving Cabal is no simple matter, which is why Halcyon attempts to improve on Cabal from the outside. Can you check if |
Running Executed in that order without any I'm using IntelliJ as the IDE, but I'm building on the command line because the Haskell support is flakey (ghc-modi crashes a lot). Right now I'm setting up private storage, so that's from-scratch rebuilds should be ok. |
Is there an option to exclude certain things from the sandbox tar? It's picking up the old EDIT: |
It sounds like you’re talking about build directory archives, which are named A build directory starts as a copy of your source directory, so yes — it’s a good idea to avoid unnecessary source files. Right now, there’s no option to avoid copying certain source files — only an option to avoid hashing them, You can disable the creating and uploading of archives with Currently, it’s not possible to disable stripping the app. This is now tracked as part as #54. |
Ok thanks for the clarification. I am of the opinion that it should leave out I did discover the NO_UPLOAD option -- saves a 3 MB upload every time and I'm now getting 6 seconds halcyon builds -- thanks. |
The purpose of archiving a build directory, There is an additional subtlety — a source directory may include a partial It occurred to me that rather than an option to avoid copying certain files, your use case would be better served by being able to keep build products in the source directory (#14). |
Ok, please excuse my ignorance -- I wasn't aware of how halcyon worked. So... it copies the source dir (the working directory) to a temporary dir, and does the build there? (and copies the build artifacts somewhere else if you used Looking through Halcyon source, it looks like it's a bit of a pain to exclude things from the archive, unless they're not copied in the first place. At the moment, now that I've removed the extraneous things from my source dir, I'm ok with living with I would probably better off if the build could be executed in the source dir (or copy the artifacts back there), because my acceptance tests expect the executable to be where cabal would put it. However at the moment, I think a once off |
With 3419002, you can now disable stripping the app by setting |
@thorinii: Please let me know if this helps. |
There's not really much difference (it downloaded an old build dir from S3). If I was in the mood to save one second, I'd also turn of self-updating while I'm at it. But I'm realising now that Halcyon was not originally designed for live development work. It's a tool for build servers/Heroku to get maximal performance in not-so-often but repeated builds. Not for running every half-minute in a coding cycle. It's useful for prepping the dependencies etc at the beginning of a the coding session though. Thanks for your work. |
You’re welcome. While you’re correct that Halcyon grew out of the Haskell on Heroku project, supporting incremental development was my goal from the start. In fact, at one point, I was able to complete remote builds, on Heroku, in under 30 seconds — from I consider anything which gets in the way of incremental development to be a bug. Please continue opening issues. |
Is it possible for Halcyon have a command to copy the sandbox in /app to the local .sandbox?
Note: I'm really new to Haskell, so I don't really know what I'm doing, but when developing, I've noticed
cabal build
runs a lot faster thanhalcyon build
-- reusing the halcyon sandbox for cabal would be nice.Related to #47, this might be a duplicate.
The text was updated successfully, but these errors were encountered: