[Feature] git dependencies

[mrcjkb]

This would likely require us to create a luarocks build backend that is capable of handling it.

• Should this be its own git_dependencies table?
• Or a [dependencies].<foo>.git = github:owner/repo
• Or something that allows to embed a rockspec:

dependency_rockspecs = {
[==[
package = "foo",
version = "1.0.0",
source.url = "bla",
build = {
  type = "builtin",
},
]==],
}

Even though it's more verbose, I'm leaning towards the third option, because it's very flexible (not limited to git dependencies) and we can already encode rockspecs in the lockfile.

[vhyrro]

I guess my only gripe with all of these approaches is that they aren't compatible with the rockspec format. I see two possible approaches here:

1. We disallow a rockspec with git dependencies to be uploaded to luarocks.org (cargo does this for crates.io)
2. We instead opt for an adapter architecture (luarocks-build-git-adapter), which allows you to specify git dependencies in the build step, all while being able to specify a different build step that runs as a subcommand of sorts (e.g. build.type = "git-adapter" and build.subtype = "builtin").

[mrcjkb]

Ah crap, luarocks doesn't support any off-spec fields. That means we'd have to change it to

build = {
  dependency_rockspecs = {
[==[
package = "foo",
version = "1.0.0",
source.url = "bla",
build = {
  type = "builtin",
},
]==],
  }
}

which is kind of ugly.
But with that, luarocks won't complain (even if the rockspec uses the builtin build backend).
It'll just ignore the off-spec fields.
So I don't think it would be strictly necessary to disallow uploading rockspecs with off-spec fields to luarocks.org.

[vhyrro]

I'm of the opinion that a given rock should provide the same output no matter what plugin manager consumes it. Doing off-spec fields is dangerous in this way because it becomes an anarchy of "this package manager can build this rockspec but this one can't". I think disallowing is safer (while still making the functionality cool).