Home Download Buy Blog Forum Support

Process for Porting Plugins

Process for Porting Plugins

Postby bgreenlee on Tue Jan 29, 2013 6:01 am

Congrats on the ST3 beta. Looking good so far.

A question about porting plugins: will it be possible to have a single plugin code base that runs on both ST2 and ST3? Or will we have to create a new name/repo for the ST3 version?

Brad
bgreenlee
 
Posts: 22
Joined: Wed Jul 20, 2011 8:02 pm
Location: Seattle, WA

Re: Process for Porting Plugins

Postby sublimator on Tue Jan 29, 2013 6:47 am

bgreenlee wrote:will it be possible to have a single plugin code base that runs on both ST2 and ST3?


There's the changes between Python 2 and 3, and also those between Sublime 2 and 3. Supporting both versions of Sublime in the one code base is probably doable but I'm guessing it would come at considerable effort/complexity. Consider supporting an on_selection_modified for ST2 and an on_selection_modified_async for ST3.

I've ported some plugins to early alpha builds of ST3.

I found using the 2to3 python refactoring tool a reasonable first step, making mechanical changes for things like print() now being a function.

In earlier builds of Sublime 3, there was ONLY async on_* event handlers, so you'd get weird bugs such as the visible region changing (animated scrolling) during an on_selection_modified handler

I haven't tried this new API with on_*_async as alternatives instead of replacements.

Other than Python version, there's also the performance cost of putting the plugins out of process. This can mean you need to adjust your code, to avoid function calls, which were considerably cheaper before. An example being checking the scope for each character in the buffer.
It is better to remain silent and be thought a fool, than to speak out and remove all doubt
sublimator
 
Posts: 649
Joined: Thu Mar 20, 2008 5:41 am

Re: Process for Porting Plugins

Postby ggreer on Tue Jan 29, 2013 9:33 am

I also recommend 2to3 for the initial conversion. Running
Code: Select all
2to3 -w .
in your plugin's directory should get you started. Be careful though: Python 3 is not backwards compatible. Your converted plugin will most likely break in Sublime Text 2.

I've started toying with converting a plugin, and I think I've found an issue in the ST3 beta. Where should we report these issues with plugin development? For example, on OS X I can't import urllib.request:

Code: Select all
>>> import urllib.request
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "X/urllib/request.py", line 2456, in <module>
ImportError: No module named '_scproxy'


Also, now that Sublime Text 3 ships with its own Python on all platforms, can we count on modules being consistent everywhere? Sublime Text 2 had some issues with the ssl and select modules on Linux and Windows, respectively.
ggreer
 
Posts: 3
Joined: Tue Jan 29, 2013 9:03 am
Location: San Francisco

Re: Process for Porting Plugins

Postby sublimator on Tue Jan 29, 2013 9:56 am

Yeah, it really sucks about the missing modules.

I'm not entirely sure if it's due to technical reasons, whether they are surmountable or if some kind of licensing restrictions on static builds.
It is better to remain silent and be thought a fool, than to speak out and remove all doubt
sublimator
 
Posts: 649
Joined: Thu Mar 20, 2008 5:41 am

Re: Process for Porting Plugins

Postby wbond on Tue Jan 29, 2013 3:56 pm

ggreer wrote:Also, now that Sublime Text 3 ships with its own Python on all platforms, can we count on modules being consistent everywhere? Sublime Text 2 had some issues with the ssl and select modules on Linux and Windows, respectively.


The issue with SSL is a linking issue and the fact that different linux distros all come with different versions of OpenSSL. You can work around it, but it requires custom patching the ssl module and bundling multiple _ssl.so files. My guess is that it is just kinda low priority for Jon since Linux users tend to have curl or wget available also.
wbond
 
Posts: 528
Joined: Mon Feb 28, 2011 5:33 am

Re: Process for Porting Plugins

Postby ggreer on Wed Jan 30, 2013 2:07 am

I've run into some rather important missing/broken modules so far.

ST3 beta on OS X:
Code: Select all
>>> import urllib.request
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "X/urllib/request.py", line 2456, in <module>
ImportError: No module named '_scproxy'
>>> import ssl
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "X/ssl.py", line 60, in <module>
ImportError: No module named '_ssl'


and on Windows (32 bit):
Code: Select all
>>> import urllib.request
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "X/urllib/request.py", line 88, in <module>
  File "X/http/client.py", line 69, in <module>
  File "X/email/parser.py", line 12, in <module>
  File "X/email/feedparser.py", line 27, in <module>
  File "X/email/message.py", line 16, in <module>
ImportError: cannot import name utils
>>> import ssl
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "X/ssl.py", line 60, in <module>
ImportError: No module named '_ssl'
>>> import socket
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "X/socket.py", line 47, in <module>
ImportError: No module named '_socket'


I'm guessing the ssl and urllib modules are broken on Linux as well. I don't know why sockets are missing on Windows. Unlike ST2, the select module exists in ST3. Unfortunately, Python's select only works on sockets in Windows. :/

I think the lack of urllib.request and ssl are the biggest issues. One way to fix ssl would be to include a static OpenSSL library in Sublime Text 3 builds. On Linux, that's a .a instead of a .so file. OpenSSL's license allows for this. (It's Apache 1.0 & 4-clause BSD.) This may seem difficult, but in the long run it will result in a much healthier plugin ecosystem. It will prevent countless bugs caused by different plugin developers writing their own hacky workarounds for missing Python modules.

I really, really hope these modules get fixed. It would allow for quite a few new and interesting plugin possibilities.
ggreer
 
Posts: 3
Joined: Tue Jan 29, 2013 9:03 am
Location: San Francisco

Re: Process for Porting Plugins

Postby sublimator on Wed Jan 30, 2013 5:00 am

Yes, if it can be done, it SHOULD be done, no question, IMO
It is better to remain silent and be thought a fool, than to speak out and remove all doubt
sublimator
 
Posts: 649
Joined: Thu Mar 20, 2008 5:41 am

Re: Process for Porting Plugins

Postby jfromaniello on Wed Jan 30, 2013 3:03 pm

same issue than @ggreer . It seems that ST3 for Windows doesn't come with SSL.

ST2 for windows has ssl, not sure about OSx.

This is a problem for sure because most windows users doesn't have curl or wget.


thanks,
jfromaniello
 
Posts: 14
Joined: Tue Sep 27, 2011 2:48 pm

Re: Process for Porting Plugins

Postby wbond on Wed Jan 30, 2013 6:20 pm

I followed up with Jon via email asking if we can get ssl on Windows in the next build.
wbond
 
Posts: 528
Joined: Mon Feb 28, 2011 5:33 am

Re: Process for Porting Plugins

Postby LONGMAN on Fri Feb 01, 2013 1:06 pm

Import not works in Python 3?
ImportError: No module named 'blablabla'
AutoBackups: ST2 / ST3
CodeFormatter: ST2 / ST3
StringUtilities: ST2 / ST3
LONGMAN
 
Posts: 68
Joined: Mon Nov 26, 2012 5:03 pm
Location: Tbilisi, Georgia

Next

Return to Plugin Development

Who is online

Users browsing this forum: No registered users and 5 guests