That’s something I’ve been thinking about for quite a while now, but I don’t see any satisfactory solution… Without a proper package manager supporting versioning, name conflict resolution, etc., it’s going to be a pretty messy arrangement whichever way you approach it. I don’t know of any light-weight editor that sophisticated with this regard (maybe jEdit?).
In my view, Sublime would ideally be able to use the system’s Python —as opposed to an embedded one—, so packages could conceivably be managed through PyPI. I don’t know whether this is technically possible, but since the infrastructure’s in place already, it looks like the easiest solution to this problem. However, requiring users to download and install both Sublime and Python would raise the entry bar for many users, so it probably goes against Jon’s priorities.
Creating a full new package for every plugin seems to be overkill. I think grouping small plugins in a “Plugins/Text/Source” package is the best way to go at the moment… Unfortunately, I don’t think Mercurial or git (most plugins if not all are hosted either at Bitbucket or GitHub) let you clone single files from a repo. And I don’t think anybody would like to blindly download all the plugins in the org.
So assuming this was the preferred way to deal with loose plugins, I see two compatible options:
- We create a Plugins repo in the GitHub org off of which everyone can work
- Plugin developers use the system that suits them best and provide a “Plugins.sublime-package” file for download. Sublime will copy the files to the Packages/Plugins folder on its own.
This won’t solve any of the main problems, but at least there’d be a consistent way of obtaining plugins…
With regards to creating .sublime-package files, you might want to take a look at:
bitbucket.org/guillermooo/aaapa … 0/setup.py
I put together a very hackish distutils command (spa) that will collect the files and create the “.sublime-package” for you. But the code might be considered a criminal offense in many countries.