Local dependencies in the package-set

[btrepp]

Coming from using bower I'm missing bower link, spago is making it easier to consume others libraries but using bower it's damn handy to be able to link against local versions of packages when developing libraries/verifying changes etc.

Two options I can think of thus far.

1. Dropping a symlink to .spago/package/local/
2. Playing with packages .dhall to link in the other package.

The first is simple, but if your package has other deps it could be a fun little dependency hell.

For the latter, dhall is powerful enough that you can do things like

let tiled = ../tiled/spago.dhall

let mkPackage =
      https://raw.githubusercontent.com/spacchetti/spacchetti/20190105/src/mkPackage.dhall sha256:90974a8e07650e49a4197d4ce5b59e82740fd8469c8c1b9793939845ca8faad9

let upstream =
      https://raw.githubusercontent.com/spacchetti/spacchetti/20190105/src/packages.dhall sha256:04da9c924e05cb6b43447ffd13408d01992f3172eb80d5d94e7f1b14c76a5123

let overrides = {=}

let additions = 
    { tiled  = 
        mkPackage 
          tiled.dependencies
          "..\\..\\..\\..\\tiled"
          "master"
    }

let tiledset = tiled.packages    

in  upstream ⫽ overrides ⫽ additions // tiledset

This works, with the caveat that if you update the repo's master, you need to delete .spago\tiled\master\ to get spago install to copy everything again.

I can also appreciate that it's better to guide everyone to contribute more to the package sets, but this is more of a situation where having my own forked spachetti set/ overrides seems a tad overkill, especially as I'm still experimenting with what the 'package' should look like, so there's little purposing in publishing any of it.. yet.

[f-f]

This is a good analysis, and I'd lean against the second solution here - mainly because we're almost there, and because bower link is imperative and side-effectful, while just "using the path of existing source" is pretty declarative.

What's missing from the current implementation to be able to just use local paths is that in case we have a local path the package still gets copied to the .spago folder. But we should instead detect if it's a URL or a local path, and just include the path in the list of blobs we pass to purs.

Implementation draft:

• add a isLocalPackage fn to detect if it's a local path
• if local, return the original folder instead of the .spago one in getPackageDir
• if local, filter it out from deps when doing install

[btrepp]

I was playing around and found a much simpler way of doing this. Which actually feels quite nice. Granted there's a big chance of here be dragons with your packages (but spago.dhall is being fairly honest about it)

let tiled = ../purescript-tiled/spago.dhall
let pixi = ../purescript-pixijs/spago.dhall

in { name =
    "my-project"
, dependencies =
    [ "effect", "console", "web-html", "affjax", "argonaut", "debug" ] 
    # tiled.dependencies
    # pixi.dependencies
, packages =
    ./packages.dhall 
    // tiled.packages 
    // pixi.packages
}

then building using
spago build -p "..\purescript-tiled\src\**\*.purs" -p "..\purescript-pixijs\src\**\*.purs"

I'm actually a big fan of how this is pretty explicit on what order/packages/dependencies are getting pulled in, the only annoying UX is that spago build command is quite long.

[f-f]

@btrepp it's cool that this approach works as well :)

However I'd prefer going with the "add local packages to package-set" vs the "add local packages to your config", for several reasons:

• as you said, merging the package sets is quite risky: what if the package sets contain different versions of packages, and e.g. pulling in pixi.packages downgrades a dependency for tiled?
• if you add the packages to the config you can only have additions to the package set, but not overrides - e.g. what if I want to fix simple-json and use the local fork? Adding them to the package-set allows you to override existing ones as well.
• it is useful to keep the distinction between "packages in the pool", "packages we're building with", and "our sources". Adding the local packages to the config would blend in "our sources", potentially introducing confusion. Instead adding them to the package set is just a normal addition/override
• other package managers keep the above distinction as well. E.g. in stack local packages are added to the package-set (in stack.yaml), and dependencies (including local ones) are specified in the package config (package.yaml)
• local packages would show up in list-packages

I put together an implementation in #96, could you test if it works for your use-case?