Sublime Text's Plugin API: It's Python, Sort Of

Atom may have more momentum and plugins than Sublime right now, but since the core is built upon Chromium rather than Jon's custom beautiful and latency-free cross platform UI framework, it will never suit everyone's needs of performance and responsiveness. The world needs a good native, fast editor with a focus on mouse pointer editing, but only gvim is a viable (and bloated) contender.

Donations for software like this works fantastically, as I know from experience, and the increased momentum of an open source release would increase the number of commercial users willing to ethically support the project. However, if it remains proprietary, ST is still a respectable editor I will be using for the next decade.

https://twistedmatrix.com/users/glyph/rant/extendit.html

See also this comment of his on Advogato, which he indirectly referenced in the previous article:

http://advogato.org/article/550.html#12

Unfortunately, ST3 is in one of those death-march betas that have been ongoing for years, fragmenting the plugin space. If you write a plugin for ST, you either need to write Python that simultaneously targets Python 2 and Python 3 (possible, but restrictive), or you need to maintain two versions of your plugin.

Sublime Text 2 on Windows has an error when importing select. It isn't that Jon didn't include select, but rather there seems to be an issue importing the select.pyd from the folder that sublime_text.exe is located in, with Python 2.6. In fact, Python 2.6 on Windows has all sorts of issues that Jon burned a lot of time trying to work around. For instance, Python 2.6 can't add sys.path entries for folders with non-ascii characters. This led to a hacky work-around where Sublime Text chdirs into each package folder and loads the Python from ".\". Package Control solves the select import by shipping the select.pyd files, but placing them in a package folder and then adding that folder to sys.path.

For Linux, Python creates a _ssl.so shared library shim that links with the system's version of OpenSSL. The downside is that different distros have different versions of OpenSSL - 0.9.x and 1.x.x. This is further compounded by the fact that Fedora has their own specially numbered version of libssl (libssl-10 instead of libssl-1.0.0). So, by distributing a compiled version of Python, there isn't a way to ship the _ssl module for Python that will actually consistently work. Jon seems to have decided to focus his energy on other issues. Package Control patches this issue also. Actually, my SFTP package was the first to patch the issue, but I spent the time to make in generally available to all packages with Package Control 3.0.

So there are two options to deal with _ssl. Jon could try to ship OpenSSL with Sublime Text, thus entering the world of being responsible for patching OpenSSL, and dealing with dynamic linking issues and all that jazz. It gets kind of gross dealing with rpath and all kinds of other work to get the shared lib to look in the current folder first rather than loading the, possibly incorrect, system version of libssl. I've gone down that path before with a project and it was not a fun time. On a side note, Sublime Text on Windows unfortunately does ship OpenSSL, so the version available to Sublime Text plugins can be out-of-date. I've been working on a cross-platform crypto library for Python that uses the OS crypto facilities, which could be a solution for this in the future.

The other option is to rely on the system version of OpenSSL, but provide _ssl.so shims for each of the different major versions of OpenSSL for each architecture. Then ssl.py would have to be patched to try each of the shims until one of them loaded properly. The upside here is that the distro is responsible for updates to OpenSSL. This general approach is what Package Control does, however I don't patch ssl.py. Instead Package Control adds a custom package that is listed alphabetically first, and thus loaded by Sublime Text first. This custom package tries importing each of the shims until it finds one that works with the version of OpenSSL on the system. If you are morbidly curious, you can see the code and shims at https://github.com/codexns/sublime-ssl-linux.

The end result of all of this is that for the majority of ST users, these issues are likely solved. Package Control 3.0 automatically installs these fixes, and provides mechanisms for package developers to share other compiled Python modules. Older versions of Package Control have been EOLed, and thus it is possible for package developers to rely on users having these patches in place.