CCW should notify about updates to user plugins

[asampal]

It would be nice if remote updates to plugins were detected and the user was notified of this. Perhaps this update check could be done through the team API if the VCS metainfo was preserved.

[laurentpetit]

This feature can certainly be created in ccw-plugin-manager. CCW already requires that the installed Eclipse has Git support since it uses JGit explicitly, so ccw-plugin-manager can at least rely on JGit.

Going through the team API could offer more feature, such as benefiting out-of-the-box from Eclipse proxy settings, stored user credentials (though not for this use case, which is a read-only on public git repository) scenario.

[asampal]

Well, I don't know any of these APIs to be able to suggest one over another; I just suggested the team one because I assumed any specific APIs would be abstracted under that, and there are still some people out there using SVN, HG, etc. Btw, what kind of a vacation is this? :-)

[laurentpetit]

The kind where children play on the iPad when the sun is at its zenith :)

Since plugins embedded within ccw are stored in GitHub repositories, I think we can safely assume that if a user has cloned them inside their ~/.ccw folder, it is also as a git repository.

We could also turn the problem upside down, and embark the .git/ history of each embedded user plugin inside ccw. Then we could see whether the sha1 of the user plugins inside ~/.ccw correspond to an existing Tree in the git database.

All this is really open brainstorming.

I'm also wondering if we could decouple lifecycle of embedded user plugins and update them independently from updating the ccw plugin, for instance.

Also, a mode that could automatically revert the user plugin to the previous git commit if it does not load properly, etc. (holidays musings :-) )

Le jeudi 9 juillet 2015, Adrian Sampaleanu notifications@github.com a écrit :

Well, I don't know any of these APIs to be able to suggest one over another; I just suggested the team one because I assumed any specific APIs would be abstracted under that, and there are still some people out there using SVN, HG, etc. Btw, what kind of a vacation is this? :-)

— Reply to this email directly or view it on GitHub https://github.com/laurentpetit/ccw/issues/807#issuecomment-119772151.

Laurent Petit

[asampal]

I suppose before embarking on some kind of more serious package/package repository management implementation, it would help if you put down your thoughts on how you see user plugins evolving. For example: Will there be a need for supporting native libraries any time soon? If yes, would the native parts be built locally on the user's system as with npm packages, for example? Will dependencies among user plugins be allowed at some point? How important do you think a central registry is, to allow for either manual or automatic search-based lookup?

I'm guessing that, at least at first, you want a lightweight approach to managing user plugins. How about taking some cues from Sublime Text which has formed a really nice ecosystem of user plugins managed with what seems to be a relatively simple approach in Package Control. ST is in a similar situation to CCW, being a multi-platform editor where user plugins can depend on native libraries and where some subset of the plugins can be bundled with releases of ST.

From the shallow understanding I have, there is no server to front the package registry - it is simply a repo on GitHub where the package authors do the manual work of updating the appropriate files to add their plugins to the registry of known packages. Updates to user packages, I think, are automatically detected by the Package Control package based on tags containing semantic versions being applied to the respective contributing repos.

[laurentpetit]

You're right I should put my thoughts on paper. It's still hammock time.

• native parts built locally? I doubt it, if it requires the user to install native compilers. If native parts are ever needed, then it would probably be the time to leverage the p2 mechanism with fragments per platform. And that's a whole beast in itself (would include storing the distributable p2 repository for the plugin somewhere, etc.).
• but the native parts could be downloaded just in time, e.g. leveraging leiningen dependency management under the hood. But I'm wary of using leiningen. At least it would be an implementation detail for the writer of user plugins, not to be depended on.
• dependencies among user plugins allowed? that's certainly possible, but again would probably need to address the problem of dependencies globally: with different kinds of dependencies, e.g. maven coordinates, p2 repository coordinates, user plugins coordinates.
• I think a central registry is important, and we already have it for the existing user plugins: it's the Github API when you do a prefix search for ccw-plugin-*. In the ccw-ide org if you only want to display the CCW Team provided user plugins, or without org if you want to do a broad search. From there, it will be easy to display the content of the README.md for description, with some convention on how to format the README so that we can extract a short description, usage, stability, etc. Github meta-data such as number of watchers, number of forks, last activity, etc. can also be used to sort the search results! A first version could even just be a redirection to the pre-filled github search page!

You're right, I want, at least at first (and this will probably be a longer period than you and I might expect), I want a lightweight approach.

I will follow your advice and do my homework by studying how Sublime Text did this. Thanks for the pointers! Do you personally know this first-hand, or is it something you've heard from?

Reading the summary you wrote about it, it's almost exactly what I have in mind.