| 1 |
On Thu, Nov 10, 2005 at 09:29:22PM -0800, Brian wrote: |
| 2 |
> On Thu, 2005-10-11 at 20:51 -0600, Brian Harring wrote: |
| 3 |
> > On Thu, Nov 10, 2005 at 06:42:54PM -0800, Brian wrote: |
| 4 |
> > > Just a quick question. With all the changes I see in this list. Is |
| 5 |
> > > there anything coming (that you know of) that will break porthole's use |
| 6 |
> > > of portage. |
| 7 |
> > Long term? I'm unfortunately looking at breaking pretty much all api |
| 8 |
> > access portage wise, for 3.0. |
| 9 |
> |
| 10 |
> I knew that one. From what I have gathered so far I believe 3.0 is |
| 11 |
> getting the long awaited public API. Is that correct? If so I'll have |
| 12 |
> to start paying more attention to it and setup a test box to start |
| 13 |
> changing our portagelib.py to use it. (I can't afford to trash my main |
| 14 |
> box, I have business stuff on it.) Just let me know when it's time for |
| 15 |
> testing. :) |
| 16 |
|
| 17 |
Actually... it's stand alone. I'm working on it alongside stable. |
| 18 |
It lives in it's own namespace python wise (rather then what stable |
| 19 |
does), so it doesn't interfere with anything :) |
| 20 |
|
| 21 |
Regarding API; yah, something will be there- I haven't thought about a |
| 22 |
true high level API for it yet, but at least the internal stuff is |
| 23 |
pretty straightforward- what it should be one things are finished up- |
| 24 |
|
| 25 |
domain=portage.config.load_config().default_domain |
| 26 |
from portage.package.atom import atom |
| 27 |
p = max(domain.repos.match(atom("dev-util/diffball"))) # get the max available version |
| 28 |
b = p.build() # get a build op |
| 29 |
b.finalize() # build the sucker |
| 30 |
domain.vdbs.add(b) |
| 31 |
|
| 32 |
Is basically what it will be; the nasty stuff required for stable |
| 33 |
won't be there, since this is actuall OOP rather then procedural |
| 34 |
spaghetti. |
| 35 |
|
| 36 |
May, or may not layer an API over it, although that's something down |
| 37 |
the line. Right now working on the v.add chunk. |
| 38 |
|
| 39 |
> > Short term? Unless you're doing questionable stuff like bypassing the |
| 40 |
> > cache layer and accessing the files on disk... nope, shouldn't hork |
| 41 |
> > anything. |
| 42 |
> > |
| 43 |
> > ~harring |
| 44 |
> |
| 45 |
> mostly just lookup stuff, get defaults, status, package info, etc.. All |
| 46 |
> emerges are done properly through a terminal and normal command line |
| 47 |
> calls. |
| 48 |
|
| 49 |
Yah, nothing that's been talked about should affect querying |
| 50 |
interfaces. |
| 51 |
~harring |
Archives