Wiki links are dead

[dbarnett]

I noticed that wiki links used in the docs and README like http://vim-wiki.mawercer.de/wiki/topic/addon-info.json.html no longer work. Should those be updated to point to an archive of that content somewhere else?

[dbarnett]

(Noticed this because I'm a fan of your addon-info.json convention and have used it in other projects and linked it from docs like https://github.com/google/vimdoc, where the links are now dead.)

[MarcWeber]

Sry, coludn't afford server so it went offline. Changed the link to webarchive. See latest commit. Looking at tools like Buck2, Bazel, Pants, Nixos I think we need a cross platform and lanuguage way to specify dependencies which resolve within a given context . Like within Debian with core packages extend with from source resolve A,B,C but that's error prone, but what developers need. Eg Brew only handles binaries for that reasons. VAM kinda went into maintenance mode because Pathogen, Vundle, and others turned more popular despite having less features. And I kinda got sick of everyone reinvents the wheel because you can without standard wasting everybodys time. Today I think the level to fix this is the language level. Like lua vs JS vs (10+ languages including Rust and ...) is fixing the language problem. Like having one language which can be complied, interpreted (like there are C++ interpreters) and also has dynamic (python like) er. The main problem is dynabmic / compiled are contrary. But you know dynamic/interpreted with some jitting (eg like JS) is fastest for developing. Eg vscode vs lapce vs Eclipse like. There is a reason vscode is often >>good enough<< proofing that jitting gets many jobs done today with fast CPUs to a degree that being able to restarting fast thus iterating fast could be more important than fastest speed. If you want to join discussing this all you're welcome. addon-info.json just was desperate attempt to get my own dependencies under control with least amount of effort assuming that using >>latest from github<< is what most people do anyway. So I think >>resolve as of date 2011-10-10 12:00 is another way to get working state from the past as alternative to fixing versions. But require databases of versions and dates. Because dependency specs if the pool changes are not very well defined unless you freeze them in lock files. But Rust by design is backward compatible and already has all this within cargo.

The pain I always experience is like cmake trying to be a package manager getting dependencies. And whenever you want to distribute something eg using nix .. it almost works. Like plugins for Krita or Blender want to be installed themselves etc. But funny you found this piece of code many years after it was written.

Checkout containers and vscode remote extension (from microsoft) feature. Nvim kinda can do similar. Vim I don't know. This might help you understand where to spend your time. Those features basically allow you to install the core of the editor on another machine or container and only have the display on your machine. So you then get local and remote plugin setups.

If you need changes to multiple projects how to commit all or none ? You can't. So Github is best we have (?) but can it still be done better ? Closing for now feel free to comment. And the problem is the user who has to try 5 ways to find out what actually works.

So dependency (or installation will work) management is little bit more complex today.

Or the question about lazy loading. Startup fast vs have everything on disk. Is it ok to get dependencies from the internet when they are need ? And complexity explodes but might maximise user experience. I mean why get all of gimp if you only use 3 filters most of the time ? On application level why compile everything of an app if you only want to run and focus on 2 test cases ? So even the package and application levels kinda blur. Same Nix vs Bazel/Buck/pants ..

So what's left? "Platforms" avoiding dependency hell. Declaring the following 25 packages with version 10 will always have same version and work together. And solving is much faster. Many things have changed since addon-info was introduced. Hope this info helps you. https://mumind.me/projects -> github google vim team. Looks like you have some dead links, too :-)

https://github.com/folke/lazy.nvim was one alternative solution which eventually is a better bet on the future. While lua might be faster some stuff like regex are easier with Vim. So eventually calling from Lua into Vim is sane solution fore some tasks ;)

[dbarnett]

Changed the link to webarchive.

Thanks, same solution I used in https://github.com/google/vimdoc/pull/137. FWIW there are still a bunch of links in the README that aren't update.

But funny you found this piece of code many years after it was written.

I've been using it since 2014: https://github.com/google/vimdoc/commit/9604ec76969783a814fc1e65d9216772776d83c0 =)

https://mumind.me/projects -> github google vim team. Looks like you have some dead links, too :-)

Oh, weird... might only be accessible to people who are actually members of the "google" org (which I'm not anymore, so it's a dead link for me too).

Anyway I still like the addon-info.json convention, whether it's considered "a VAM thing" or not, and have integrated support for it into lots of vim tooling over the years (that vimdoc project, the maktaba helper library, schemastore...). It doesn't have to solve every use case to be valuable, dependency management is hard but I hadn't relied too heavily on those advanced parts of the spec. I'm not actually using VAM these days so no worries about keeping stuff in this repo up-to-date, but I think I'd still like to publish an explanation of the addon-info.json format somewhere and would welcome your input on it.