On Mon, 2014-01-13 at 15:46 +0100, Tom Wijsman wrote: > On Mon, 13 Jan 2014 16:15:37 +0700 > "C. Bergström" <cbergst...@pathscale.com> wrote: > > > Long term the API to pkgcore could be beneficial, but > > again I'm not sure it's a game changer for users. > > Long term, we should have an independent API backend that tools can > query; not rewrite our tools every time users want to use them with a > different package manager. >
I have been working towards that for years, but, things keep getting in the way. By things, I mean other project work that needs to be done as well. I got started in all this working on porthole, which uses portage's api for much of it's information. To get more features, information, I wanted to be able to incorporate some of gentoolkit's info. Namely equery, but most of it's working code was embedded with it's output. I worked hard at separating out it's working code from it's output so it would be usable by other tools. I have also been working on making a pkgcore backend for porthole. In doing that it required making a different backend for portage to get some uniformity for the frontend. I have had to put development of those on hold, due to taking over layman's development. I gave it a new high level api, modified it's mid level code and gave it a nice api that can be used by other apps, guis, etc.. One of the things that came up with layman was to be able to gpg enable it to verify it's repositories.xml list it downloads. I did that. In so doing created dev-python/pyGPG a python lib, which has now brought me in to developing Gentoo-keys (another project that could use help) to manage gentoo's gpg release, developer keys, and verification. Also at the same time a year ago, there was a lot of talk about moving the default location of the gentoo tree, but it could not be done with current catalyst code. So offered to help out as that project was severely lacking people with decent python skills. That code base is like what portage code was 8 years ago. And if you thought todays portage code is bad... you would cringe to see it's code from 8 years ago. Now portage was in trouble, while there were some people stepping in to fix things, I stepped up to help drive out a new release. I am now interim lead till we hold an election. So most of my time now is spent steering projects, more than coding. Hey, it's all work that has to be done. So I'm putting out fires where it needs it most. With that aside. One of the biggest hurdles new developers face with pkgcore is the lack of decent api docs and flow charts. Brian was brilliant and OCD about attaining speed, but at the cost of difficulty in following the code and creating the steep learning curve. I have been trying to get these other projects to a point I could create the docs and charts needed so that it would be easier for new developers to find their way in pkgcores code. That is when pkgcore will make more headway at becoming portage's replacement. But some new fires keep popping up. Long story in a nutshell, gentoo could use more GOOD firefighters. Sorry for the long speech ;) your friendly gentoo python firefighter -- Brian Dolbec <dol...@gentoo.org>
signature.asc
Description: This is a digitally signed message part
