supporting python2 and python3 in kdevelop

[Sven Brauch]

2013/11/4 Milian Wolff <mail at milianw.de>:
> Personally, I'd try to merge the codebases since having two branches will be a
> nightmare for release management among other things.
What would be so terrible about it? I would just create two tags and
upload two tarballs. Can you explain?
How is it significantly different from maintaining support for an old release?

> Note that I don't suggest merging on a file level, rather on a
> branch/repository level. I.e. have a python2 and a python3 folder or similar
> in your plugin base folder.
> Thus, you also only have on ILanguageController (but two ParseJobs etc. pp.).
Hmm. One of the considerations I have for kdev-python3 is that it
works without this ugly python fork (it builds against the system's
libpython), and I thus hope that all the distros which don't ship it
today will start packaging it (there's quite a few which said "we're
not going to package it with this thing"). That gets a bit lost if I
merge the two branches into one repository (since that repository will
again contain a full copy of python).
It also makes it more difficult to merge changes between the two
branches; they are not disjoint, in fact python3 currently is a branch
of python2 and I can just merge python2 into python3 to copy new
features over. I would like to continue doing this and I don't see a
sane way to do that with two subfolders ...

> Adding configuration for your plugin to a project is also possible, no need
> for a new project manager. Then the user can specify whether a given project
> (or even file, if you want to support that) is python2 or python3.
Ah so my plugin can provide a config dialog for a project? That's good
then of course.
In this case, I guess I could just return 0 from createParseJob() in
case the plugin instance doesn't feel responsible for parsing the
file, and leave it to the other one, right? That sounds good.

Greetings,
Sven