Implement handling of local packages in the package-set

[f-f]

Implements support for local packages, as described in #88 (comment) (use case: bower link)

Basically we now try to distinguish if "URL"s in the package-set are referring to remote repos, or local filesystem path. In the latter case instead of trying to clone them, we just include their sources in the build (if they are listed as a dependency ofc). This basically mirrors the behaviour of stack.

Practical example: let's say I find a bug in simple-json. I manage to fix it locally, but I also want to see if the fix works for my project.

Since simple-json is already in the package-set, I can add the local package to the overrides in packages.dhall:

...

let overrides = { simple-json = upstream.simple-json // { repo = "../purescript-simple-json" } }

...

Note that if I list-packages, it is correctly listed as a local package:

$ spago list-packages
...
signal                v10.1.0   Remote "https://github.com/bodil/purescript-signal.git"
sijidou               v0.1.0    Remote "https://github.com/justinwoo/purescript-sijidou.git"
simple-json           v4.4.0    Local "../purescript-simple-json"
simple-json-generics  v0.1.0    Remote "https://github.com/justinwoo/purescript-simple-json-generics.git"
smolder               v11.0.1   Remote "https://github.com/bodil/purescript-smolder.git"
...

After adding it to the dependencies in spago.dhall, if I do spago install, it will not download it, but only its dependencies:

$ spago install
Installing 42 dependencies.
...
Installing "distributive"
Installing "refs"
Installing "identity"
Skipping package "simple-json", using local path: "../purescript-simple-json"
Installing "control"
Installing "enums"
Installing "st"
...

[btrepp]

UX on this is pretty good, though you still need to specify the upstream dependencies. Granted not everyone would run into this.

You still need to do something like

let additions = {
    tiled = 
        mkPackage 
            (../purescript-tiled/spago.dhall).dependencies
            "../purescript-tiled"
            "local"
    ,pixijs = 
        mkPackage
            (../purescript-pixijs/spago.dhall).dependencies
            "../purescript-pixijs"
            "local"
}

Which isn't bad (unfortunately I can't find a way of dynamically building that as a dhall function). So this works great for me

[justinwoo]

You could use record update on those, right? It's just that you need to override the url section?

[f-f]

@justinwoo: note that his example has additions, not overrides, so you need to specify the dependencies somehow: either listing them or pulling them from a spago config if the package you're importing has one

@btrepp: I'll add this note to the README

[justinwoo]

So in this case you'd want to have a new mkPackage function that can make local library package definitions? Where one of the args passed in would be either the path or the imported record?

[f-f]

@justinwoo could you make an example of how it would look like?

I though about having a mkLocalPackage that takes only two args (path and deps), but in the end it's not worth it, because a usecase could be that once you upload your package, you just swap the local package with the URL of the new git repo. After all I'm not even sure we need mkPackage, since it's just producing a record.

[justinwoo]

mkLocalPackage would be useful enough. mkPackage is also fine overall since you know that's what you're making rather than just some random record that you hope is fine, and also since you want to ensure that records are of type Package.