Aids for managing/purging the Plugins folder?

livemixer

As my collection of plugins grows & changes, it becomes increasingly difficult to know which items in the SU Plugins folder are no longer needed because they support only a plugin I have deleted. This is mostly because there doesn't seem to be any consensus about the best way to supply support items: some authors use a single, top level .rb file & one or more folders for icons, libraries of supporting ruby files, documentation, & so on ... & some supply all or part of the required rubies as separate top level files, sometimes with names dissimilar enough that it isn't at all obvious they are all part of the same set.

I understand why that happens but I wonder if anyone has thought about or already created any tools that would help users identify unneeded "orphaned" items, & possibly also clearly identify which installed plugins are missing required support files. (Ruby console error messages are not particularly good in this respect.)

I have some half-baked ideas about how to create a stand alone tool to help with this, but they all depend on features specific to Mac OS X (Folder Actions, HFS+ file system attributes, Spotlight searches, etc.) & I have no idea if they would work or be useful to enough Mac users to justify trying to develop them.

Obviously, a cross-platform approach would be more useful, possibly one that leverages ruby files from within SU itself, but I haven't a clue how feasible that would be.

Any thoughts on this would be greatly appreciated.

TIA

Aerilius

This is indeed an issue that should be streamlined/standardized somewhen in near future. It is recommended that developers use only one loader file and one folder both with same name and an author prefix (that way alphabetic sorting gives a good order). But that doesn't help much for you.

I usually move all files where I'm unsure into a separate folder. If one of my favorite plugins complains (require... or could not find...), then I add that file back. Time-consuming, but well...

A more sophisticated strategy is to add several plugin folders (by adding them to the load path, using for example AdditionalPluginFolders). Then you could have one folder for your permanent plugins, one for often used ones that you might remove somewhen, and one for experimenting (those that you most likely remove soon).

livemixer

The one loader file/one folder per plugin approach has a few limitations. In particular, it isn't very conducive to the inclusion of shared resources (like LibFredo) that many different plugins use. I think that is a great idea: it reduces the size of downloads & the footprint of the Plugins folder, makes development easier, & potentially could simplify user management of plugins, especially if different developers were able to reliably leverage each other's resources instead of "reinventing the wheel" every time they need something that already exists.

I am aware there are potential problems with that approach too, like an update of one author's library breaking another author's plugin that relies on it, but I think that could be minimized & might even result in better, more robust code.

livemixer

@unknownuser said:

Sorry to drift off subject.

Ken, thanks for you forbearance.

Since my topic was intended to discuss anything that helps make managing plugins easier, your comments did not seem off-topic to me.

About your #1 point, there is already a list of "quarantined" plugins that cause problems in this forum. And the plugin gurus already seem quite generous in posting advice about how to improve plugins. Besides, it often isn't so much that an early version of a plugin has any real errors but that it just needs a little tweaking to handle special cases or extend its usefulness.

Regarding your database approach, I would like to see something sort of like that built into SU itself, or possibly in a companion app. As I envision it, it would be OS-specific & integrate tightly with the OS's existing file database services. I don't know much about how Windows handles that but for example OS X maintains a built-in, schema-based database of file attributes that can easily be extended to include almost any sort of metadata imaginable (via what Apple calls "Spotlight" plugins).

I think it should be possible to create an OS X Spotlight plugin that automatically parses SU Ruby files to catalog their SU plugin dependencies & add that info to the metadata store, or failing that at least build an Applescript app or Automator action or shell script to add that data to the Finder's "Get Info" comments field (which is also included in the metadata database). That would enable users to search for plugin dependencies using the built-in Spotlight search engine, or at least to see them in the "Get Info" comments.

As I said, this is all still a half-baked idea I've only just started thinking about, & I don't know anything about how to implement something similar in Windows, but I hope you get the general idea: I'm hoping for an approach to SU plugin management that requires little or no manual effort by users, provides plugin dependency info in a simple, easy to understand format, & doesn't unnecessarily restrict plugin developers to some standard that might stifle innovations.

It's a tall order I know, but I can dream, right?

ken

Feel your pain.

Unlike the above post, I don't move what I would call orphan files, I change the file type from .rb or what ever is the orphan's file name extension to .ken. This way I can sort of file types and see all the files that I have some concerns. I also do this with folders, adding the ken to the front of the folder's names.

If a problem occurs, I look at the missing file if it gives an unable to load error, and I can quickly fine the folder or file.

Onto a related but other subject, I would gladly contribute to a large fund, to have the ruby gurus, look at each and every plugin, and make the following suggestions.

To the author of the plugin, how to make his plugin error free, if that is possible. Plugins that have been modified and have been given the "star of approval' to be listed in plugin in master error free list.

2.If the author doesn't have the time of maybe not the knowledge, and the plugin is worthy, have one of the gurus complete the task if that is OK with the author. The guru would be paid of course.

A plugin in naming systems that gives you some kind of hint which plugin is involved when you look at the plugin in the drop down or context menus. So when you invoked a plugin and it fails, you have some idea which plugin in involved in the plugin directory.
And the last, some time ago I started a database that listed each plugin that I had on my computer, and tied context names to the plugin. Such as, if the plugin was to divided, I would list the plugin, and add the context words, divide, split, cut and so on. That way I could fire up the database, and search on the function I wanted, and the database would give me my choices.

Sorry to drift off subject.

Ken, thanks for you forbearance.