Sublime Forum

Common Directory to reuse functions

#1

I saw that sublime replicated his decorator @threaded in multiple (at least 2) packages.
I don’t like such things so I searched for a solution. This is a very simple one.
Add this line in sublimeplugin.py in the program directory

sys.path.append (os.path.join (sublime.packagesPath(), 'Common')

Create directory ‘Common’ in %APPDATA%\Sublime Text\Packages
Move plugin_helpers.py or other files with commonly used objects to Common.
No other code changes are needed.

Any Comments?

0 Likes

#2

One possible angle is to start looking at resurrecting the PackageDownloader plugin;

[sublimetextwiki.com/pages/Pa ... oader.html](http://www.sublimetextwiki.com/pages/PackageDownloader.html)

This was a plugin I wrote to help people keep their systems up to date with the repo. Currently, it downloads a fixed number of packages, but it could easily be updated to allow the user to choose from a list of all the available packages in the repo.

When the user chooses a package, that packages should declare its dependencies, and the package downloader gets those as part of the update.

0 Likes

#3

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.

0 Likes

#4

Anther approach; Subversion allows you to import external branches into your working copy.

svnbook.red-bean.com/nightly/en/ … rnals.html

I believe this allows you to declare that a separate library folder should be checked out underneath the plugin folder. So you can create this in the repo;

trunk
/lib
/customplugin

and add a property to say that customplugin/importedlib is a copy of trunk/lib

This means, I believe, that when you check out customplugin, you get a copy of the lib folder at customplugin/importedlib. Any number of plugins can do the same trick, meaning that a plugin can bring in shard dependent files. This should work for both developers and for people getting the files from sublimetextwiki.com.

At least, I believe this is how things should work. Someone’ll have to try it out. I don’t know if it’ll do everything you need.

Steve
0 Likes

#5

I’ve been playing around with this in my own repository, and it seems to work fine. The summary is;

  • add a subversion property to the package directory. This should read, eg
../MyCommonLib common

When you chekc this folder out, you’ll end up with a common folder. Note that you can use relative paths to specify the common codebase.

  • Remember to include a init.py file in the common folder. This turns the common folder into a python package, allowing you to use import statements like;
import common.directoryfuncs

to include the code in common/directoryfuncs.py

  • you can add files directly into common, and normal add/commit/update operations will work as you expect, committing the details to …/MyCommonLib.
0 Likes

#6

If there’s a set of common functionality that’s used across a bunch of plugins, I’m happy to start including it in the default install of Sublime to make life a little simpler. It wouldn’t solve the issues mentioned above, but it may help.

0 Likes