Use symlinks instead of copying local/relative directories in `.halcyon/sandbox-sources`?

[danclien]

Would there be any disadvantage to symlinking local sources listed in .halcyon/sandbox-sources instead of copying them to /app/sandbox/.halcyon-sandbox-sources/?

Given...

Directory structure

We use an "uber"-repo for our code that looks similar to this:

• app/
  • .cabal-sandbox/
  • .halcyon/
    • sandbox-sources
  • lib/
    • internal-library-1/
      • internal-library-1.cabal
    • internal-library-2/
      • internal-library-2.cabal
  • src/
    • Main.hs
  • app.cabal

.halcyon/sandbox-sources

./lib/internal-library-1
./lib/internal-library-2

Goal

We want to be able to:

• Edit the files directly in app/lib/
• Use cabal build/cabal test

This wouldn't work since cabal sandbox list-sources would point to /app/sandbox/.halcyon-sandbox-sources/, and we would be editing the wrong code.

[mietek]

This seems like the right thing to do. Unfortunately, it’s not entirely straightforward to implement, as currently, the source directory is copied to a temporary location very early in the build process.

Closely related to #11 and #14.

[mietek]

Sandbox sources which are symlinks to local directories shouldn’t be archived together with the rest of the sandbox directory, because they refer to the source directory using an absolute path — which is not guaranteed to be the same between builds.

Indeed, on Heroku, builds are performed with the source code located in a randomly-named temporary directory.

Therefore, the symlinks should be recreated on every sandbox build.

[mietek]

Currently, a sandbox source change doesn’t trigger a sandbox build. The change is then detected by Cabal in the application build phase:

Some add-source dependencies have been modified. They will be reinstalled...

It’s likely some instances of the above are false positives, due to modification times not being restored for sandbox sources.

Similarly, for a Cabal package consisting of a library and an executable, with the executable depending on the library, a library source change doesn’t trigger a sandbox build.

Perhaps the process used for updating the build directory based on the source directory, which includes restoring modification times, could be generalised, extended with a hook (thoughtbot/carnival#178 (comment)), and applied to updating sandbox sources.

CC @pbrisbin

[pyrtsa]

Seems to me I'm touching this issue too with this Halcyon-enabling pull request to our project using an untagged version of https://github.com/haskell-game/sdl2 as a dependency.

In the build log (1.txt was built from scratch), we can see that Halcyon / Cabal try to build sdl2 twice in the process, with some spurious warnings logged: https://gist.github.com/pyrtsa/4f68fc3f69fe1a76b595#file-1-txt-L210-L233.

[mietek]

I’m sorry. This project is no longer maintained.