ii14
ii14
Okay, sorry, I can see the point now. In my opinion dependencies should always have the full URI.
That's how I imagined it, that it's essentially just a list of URIs with some metadata, just like most vim plugin managers work. For git I figured you'd just use...
This is pretty much a duplicate of #19 `neovim` is not top-level, it's under `dependencies`. What I was thinking is just leaving those "special" dependencies, "engines" or whatever you want...
@numToStr I'm not against this, but I think you can just add them directly to `dependencies`.
> So, RPC/vim I think should probably not be included. @mjlbach Even if it appears useless and is not supported by the spec right now, I don't think we should...
Some sort of cleanup hook could be useful (to uninstall previous version for example), but is there actually any use case for having the update hook (I assume it's after...
```lua hooks = { ["linux,mac"] = { build = [[...]], clean = [[...]], }, ["win"] = { build = [[...]], clean = [[...]], }, } hooks = { build =...
@mhanberg I think how is it handled should just be implementation defined, and a package manager could let you audit what it is that it's about to run. And plugins...
> My 2 cents is I dislike `specification_version` as not being intent specific enough. I prefer `packspec` but would prefer something even more descriptive. Examples were not updated, the schema...
The idea is to have multiple versions of the same package? I think in order for that to be a thing, dependencies would have to explicitly declare that they promise...