supporting python2 and python3 in kdevelop

[Milian Wolff]

On Monday 04 November 2013 18:01:17 Sven Brauch wrote:
> 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?

It's just more work. (stable + master) x 2, i.e. twice the work ;-)

> > 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).

That is a valid concern and indeed might be something in favor of the two 
distinct branches.

> 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 ...

If you can merge changes, then you could also reuse code, no?

> > 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.

As I said on IRC, it's another kcm plugin, similar to e.g. what I added in the 
projectfilter.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de