Thanks for the insight. I never looked at AAALoadFirstExtensions because I thought I don’t need ‘FirstExtensions’. I also looked at Plugins PackageDownloader package.
Reading and thinking about it I came to this preliminary conclusions:
-
Altering sys.path is currently not an option because of unicode problems and high effort
-
A library to reuse code will be fine
-
Users will prefer self contained packages.
Only plugin developers may be interested in a library. I suggest to
-
rename the Plugins package to PluginDevelopment
-
enhance the Lib subdir with a lot of goodies like threaded.py, wich can be copied to the plugin in development.
-
create some more snippets to possibly standardize plugin code to some degree
-
No commands here please! They should move to seperate plugins (Text ?).
This solution provides a library for reuse and self contained packages. It is quite simple and to the developers to feed the library.
Not solved is the dependecy problem between packages.
Extending PackageDownloader is not bad, but there has to be someone who takes care to define the dependencies. As nobody will do this a dependency analyser should be developed to do the job.
The analyser may get the information from init.py. The dependent plugin should define which plugins are needed. Somewhat like this:
if not os.path.exists ('../CTags/ctags.py'):
sublime.statusmessage ('please install package CTags')
do_something_to_prevent_plugin_from_execution_or_to_download_CTags()
The packages are self-managed and PackageDownloader is not needed for this purpose. Although I like the idea of a package manager which is highlighting updated packages - but this is a different thread.
Hmm, rereading my test I see that you can force the user to install a common package. But self contained packages are prefered for easy installation.
I hope this discussion will lead to a simple and robust solution to reuse code.