Saturday, March 16, 2013

PyDev funding and LiClipse?

I got some feedback related to the creation of LiClipse and its relation with PyDev in the current crowdfunding proposal (http://igg.me/at/liclipse/), so, I'd like to explain how I believe things fit together.

1. So, is LiClipse a fork of Eclipse?

Definitely not. The idea behind LiClipse is having 2 things:
  • A way to theme Eclipse itself better and have some other UI improvements (I'm truly annoyed by not having what I'd consider a professional dark theme in Eclipse right now, so, I'd like to take those matters in my own hands).
  • An editor which should be able to support lots of languages out of the box. Think something closer to other all-purpose editors -- as opposed to IDEs -- such as Notepad++, Vi, TextMate, Sublime, etc. i.e.: the idea is supporting lots of languages out of the box, so, the idea is having it resembling formats such as ultraedit wordfiles or TextMate language files.
To be clear, the idea is not to replace the more advanced editors inside Eclipse for each language, but to provide a lightweight way to deal with any language -- usually you work with 1 or 2 main languages, for which you'll have the plugins you need, but sometimes, when you just want to open a file in a language  you work seldomly and may not need/want to install a bulkier plugin, LiClipse would be a good addition to your toolbox (LiClipse is a short for "Lightweight Eclipse" BTW), and for me, not having this is a major shortcoming of Eclipse itself (and it may be an alternative for people who want less features and more speed).

Also, that should be doable without having to create a fork of Eclipse (although some theming issues may need to be resolved at Eclipse itself -- but on those parts, things should be fixed at that level, not on LiClipse).

2. How does that relate to PyDev?

Well, PyDev is very tightly bound to the environment it works on (Eclipse), and I'd like to solve some of the issues I see in it to improve its ecosystem as a whole, which IMHO is something I see needed for PyDev and Eclipse itself to keep moving forward.

3. But won't that divert too many resources out of PyDev itself?

For this proposal, my plan is spending my time 50/50 (I don't think LiClipse is a major undertaking -- all the pieces are out there, it's mostly a matter of stitching them together), although during that time, yes, it'll divert some resources from PyDev, but as I think that having it is very important for PyDev itself (as well as other language), I see the issues being tackled as very serious shortcomings of Eclipse which hinder the adoption of Eclipse itself (thus affecting PyDev directly).

4. I still think LiClipse is not a good idea and would like to support only PyDev.

Please e-mail me with those thoughts. I really believe LiClipse is needed for PyDev to keep getting traction, but if you feel that's not the case, please, please share your thoughts with me.

Also, just to make things clear, if the funding at http://igg.me/at/liclipse/ does not succeed, I won't really be able to support PyDev itself anymore (personally, I really want it to succeed, but I see the funding as the community speaking, so, if after 10 years working on it the PyDev community doesn't see it as a worthy goal or doesn't trust me enough to support me on LiClipse while properly maintaining PyDev, well, I really need to hear it and move on -- as a note, until now, I see the funding as a huge success, getting to 10% in the first day, so, if everyone keeps helping a bit there, it'll be awesome :)

14 comments:

Paulo Almeida said...

I don't know if LiClipse is needed for PyDev to gain traction; I don't have any data on that issue (do you, even if anecdotal?). What I can say is that I may consider supporting PyDev, but I wasn't happy to see it tied to LiClipse and theming, and knowing that it will be 50/50 makes me even more reluctant (I had thought LiClipse would be residual).

Fabio Zadrozny said...

Well, I only have anecdotal evidence on that, seeing some close people which were using PyDev go to other options specifically because of UI issues (such as the lack of a proper dark UI) and perceiving Eclipse as too bulky (which it really becomes if you install many plugins, even if you use some of those only for side-languages) -- on a side note, I got some comments from people saying that that's the main reason why they're funding it.

Unfortunately, I believe Eclipse itself has a 'bulky' image attached to it (again, only anecdotal evidence from people I talk too) and believe that really hinders its adoption (it's also the reason why the main focus on PyDev itself during the funding will be usability, speed and memory improvements).

Also, the 50/50 would be only for the duration of the funding (around 9 months). Afterwards, the idea is that it'll really be "residual" as you're saying.

Cheers,

Fabio

Fabio Zadrozny said...

Hi Paulo,

Please take a look at the comment I added at: http://pydev.blogspot.com.br/2013/03/keeping-pydev-alive-through-crowdfunding.html

I'd like to hear opinions on it.

Matt said...

Hi Fabio,

thanks for the new blog post. It still makes me wonder though who your target audience for the new project direction is, your existing user base or new users?

If you look at it from the point of view of your existing users who are using Eclipse/PyDev as it is and might have done so for many years already, they are used to the current GUI and the coloring scheme might not be such a big issue for them (if it was, they probably wouldn't have switched to Eclipse in the first place).

Then, as they are users of PyDev, they obviously want good support for Python, so supporting other languages may not have much importance to them. (Personally, I'm fine with installing the corresponding plugin if I need to use another language occasionally and if I really need to look at a file only once, I just use emacs).

So it seems that, almost by design, LiClipse is a project that doesn't really appeal to *existing* PyDev users but is instead targeted to new users who wouldn't use Eclipse/PyDev as it is now.

Fabio Zadrozny said...

Hi Matt,

I must say that I wasn't making a distinction on new users vs. existing users.

What I really want is PyDev to be the best environment for coding Python (and when I'm referring to the Python, that would also include things such as Django templates, Mako templates, restructured text and other python-related languages).

In my mind, existing users would also benefit from the enhancements, but I'm open to other opinions and will leave up to the community to choose its way (so, I've added a 'PyDev Knight' perk if you'd only like to support PyDev and not the other enhancements in the funding).

Cheers,

Fabio

Olivier said...

Hi Fabio,

How about splitting the two projects and get funding for them separately?

That way you'll know how much interest is in improving PyDev or bringing an Eclipse spinoff to the market. It will allow you to get straightforward funding from those who don't want to fund LiClipse. Also, it will give you an idea of how to split your development time.

Cheers!

Olivier said...

Hi Fabio,

How about splitting the two projects and get funding for them separately?

That way you'll know how much interest is in improving PyDev or bringing an Eclipse spinoff to the market. It will allow you to get straightforward funding from those who don't want to fund LiClipse. Also, it will give you an idea of how to split your development time.

Cheers!

Fabio Zadrozny said...

Hi Olivier,

That's already done: there's a special perk named 'PyDev Knight' which gives you the chance to support only development on PyDev itself (the discussion happened mostly at: http://pydev.blogspot.com.br/2013/03/keeping-pydev-alive-through-crowdfunding.html )

Cheers,

Fabio

Olivier said...

Hi Fabio,

So I see. I did spot it after leaving the comment.

Maybe you could make it more obvious, as there's no mention of it into the textual description. Something like "Well, I really only care about pydev, how can I contribute to its support only? => cf. Pydev Knight"

Since there's probably quite a few coming to see the page after starting up their updated Pydev plugin, Maybe that could be just after the description of liclipse before they close the page in anger? ;)

Cheers,

--
Olivier

Fabio Zadrozny said...

I've added it to the topic "What about PyDev?" (so, that's hopefully visible enough).

Cheers,

Fabio

Anders H. said...

I dropped Aptana studio and got back to Eclipse when they released with black theme. If someone wanna be an übercool hacker and use vi, please do, but get your dirty hands of my beloved Eclipse! Did those responsible really ask their users about that move? If someone wanna use a black theme they could really go and find the settings themselves, having a black theme as default was just plain stupidity. I use Eclipse because it works as every other windows program..

So, I guess this light-weight fast editor for all languages is just another way for a vi person to keep hating scrollbars and mouse usage. If they want that kind of stuff, they can do a remote login to some terminal stuff from the early 1980's.

That said, I would like eclipse to at least format every other language as well. But it's another project.

Here's my wish-list -
* Python server debugging of apache or similar server within PyDev.
* Python command line on breakpoints. Set and change variables. Evaluate the stuff as you can in the Python interpreter. Reload-modules. etc.

I do love PyDev, but I'm allergic to übercool vi hackers with a Dvorak keyboard running some obscure Linux distribution...

Fabio Zadrozny said...

Hi Anders,

Regarding Aptana Studio, I agree with you: when releasing it they didn't think things through properly (the theming had many loose ends and there wasn't a proper way to just revert things easily -- and yes, the default should not be dark -- it just takes too many people out of their comfort zone when dealing with Eclipse).

I hope to learn from those issues -- but still, not having a decent dark theme is a huge issue for many people... (note that removing the scrollbar is not really removing it, but replacing it with a component that works the same but can be themed -- the scrollbar just looks too bad on windows on a dark background -- off course you'll only care about that if you do use a dark theme).

Regarding support for other languages (which is what LiClipse proposes), for me is a dealbreaker for Eclipse/PyDev -- as it is now, you have to deal with things such as mako templates, django templates, restructured text, javascript, etc... not having those even in a simpler form within the IDE is too much of a handicap for me (it's a scenario that has become too common nowadays -- yes, its not for 100% of PyDev users, but I do think the majority will use it -- although no, I haven't really done any studies on that).

Regarding your wish list:

1. if you have apache installed locally, you can use the remote debugger already to debug it: http://pydev.org/manual_adv_remote_debugger.html

2. You can already do commands when you stop in a breakpoint. See: http://pydev.org/manual_adv_debug_console.html (note that if you're remote debugging, you may want to put stdoutToServer=True, stderrToServer=True on pydevd.settrace). Note: because of a Python limitation, you can only change variables at the topmost frame (I even issued a patch to fix that in Python once, but it didn't become integrated at the time because of the language moratorium -- maybe its time to look at that again).

3. Reloading of modules: this is mostly limited by what Python itself has as a support (I even started to do it automatically once, but in the end it was not integrated because the Python support itself is a bit fragile -- you can take a look at xreload or imp.reload in Python 3). You can use that along with issuing commands at the console.

Cheers,

Fabio

Anonymous said...

Hi Fabio,

Thank you for your continued support of PyDev and Eclipse. Without PyDev, I wouldn't be in Eclipse - it's my daily environment and I'm excited you're getting back control of the project.

I'm going to back your fundraise and not just limit support to PyDev, but please consider renaming the effort to make it clearer your goal is not to fork Eclipse. To me, LiClipse will always sound like a fork.

You seem to be focused on two distinct changes: a new editor with pluggable language support, and theming. Why not give each subproject a separate name?

I love the idea of an easily-extensible and modifiable editor, especially if defining and extending language support doesn't require writing Java.

I spend a lot of time in many languages - Erlang, Python (Flask + etc), Ruby (for Chef), various templating languages (but not Django), C/C++, etc. - and on various projects where whitespace conventions vary. For instance, the default PyDev code formatting doesn't work for one of my employer's whitespace conventions today. I'd *love* to have per-project whitespace definitions.

As for theming, I get everything I need from the http://eclipsecolorthemes.org/ project. I understand you want to go farther, but if I had to cut one feature, this would be it - especially if it means you have to make changes to the Eclipse platform that upstream will not accept.

Thank you again for all your hard work over the last 10 years - good luck with the fundraiser!

Fabio Zadrozny said...

Hi Wohali,

Regarding the whitespace conventions, and having them per-project, please buffer that request and add it to the tracker that'll be setup (working on it).

As for the name, I can only say that I'll think about it -- I must say I'm already attached to it (and hopefully it's already properly explained that it's not meant to be a fork).

I the theming area, I do intend to reuse/extend/provide back things in eclipsecolorthemes, but for me many things are still missing to make it really workable to work with a dark theme... as I posted on http://pydev.blogspot.com.br/2013/03/crowdfunding-pydev-liclipse-status.html this seems to be a really love/hate relation :)

p.s.: I've already submitted some issues/fixes back to upstream regarding the theming -- as far as the platform goes, there's not really anything that should be incompatible.