On 27/03/14 06:42, Bram Moolenaar wrote:
Since many plugins consist of several files, and we would like to check
the dependencies before downloading all the files, the best place for
these dependencies is to have them in a separate manifest file.
Another advantage is that there would be one central place where plugin
authors upload the newest manifest file. For the moment assume that's
the script storage in vim.org. This also solves the problem of scripts
on vim.org being one file.
The manifest can specify any place, including git repo's, where to fetch
the files.
One could also fetch a manifest from elsewhere (e.g. by simply editing
it) and then run the plugin installer/updater. The dependencies can be
in the form of just a plugin ID, to be found in the central repository,
but it could also be the URL of that dependency's manifest file. That
way a plugin author can also publish alpha and beta versions, with
yet unreleased dependencies, before making the fully tested plugin
available at vim.org.
Using URLs for the location is flexible and easy to debug. Using single
files avoids problems with unpacking archives, the need to first install
tools, etc. I believe all respositories support downloading individual
files. What this does NOT support is further developing the plugin or
merging local changes. Normal users won't need that.
Have you ever had the opportunity of doing ruby programming and having to
use "bundle" or some other "gem" manager? What you're proposing is very
similar and I would recommend you install ruby, play with it, and get to
know the "gem" managers before embarking down this path.
Due to the fact that such systems give the impression that it is "easy" for
the user to upgrade to the latest version, it engenders a cavalier attitude
amongst plugin writers that proper test/release control is unnecessary;
they just dump out the latest version without testing because if it contains
a bug they can just fix it and dump out yet another version with the fix.
Particularly in the workplace, and I speak from personal experience, these
kinds of systems do waste more time than they save due to everything
grinding
to a halt due when one plug-in in a dependency hierarchy breaks, normally
because the plug-in author couldn't be bothered to test their code
adequately
before releasing it. Add to this the usual system integrity problems that
accompany network-based systems and we have more headaches in the making.
If you do implement this system, may I strongly suggest that you invest more
time in the backup/rollback features than the install/management features?
That way when things go wrong we can be sure we can get back to where we
want
to get back to as quickly and as painlessly as possible.
Cheers,
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
