Re: [gentoo-portage-dev] portage and porthole
On Thu, Nov 10, 2005 at 09:29:22PM -0800, Brian wrote:
> On Thu, 2005-10-11 at 20:51 -0600, Brian Harring wrote:
> > On Thu, Nov 10, 2005 at 06:42:54PM -0800, Brian wrote:
> > > Just a quick question. With all the changes I see in this list. Is
> > > there anything coming (that you know of) that will break porthole's use
> > > of portage.
> > Long term? I'm unfortunately looking at breaking pretty much all api
> > access portage wise, for 3.0.
>
> I knew that one. From what I have gathered so far I believe 3.0 is
> getting the long awaited public API. Is that correct? If so I'll have
> to start paying more attention to it and setup a test box to start
> changing our portagelib.py to use it. (I can't afford to trash my main
> box, I have business stuff on it.) Just let me know when it's time for
> testing. :)
Actually... it's stand alone. I'm working on it alongside stable.
It lives in it's own namespace python wise (rather then what stable
does), so it doesn't interfere with anything :)
Regarding API; yah, something will be there- I haven't thought about a
true high level API for it yet, but at least the internal stuff is
pretty straightforward- what it should be one things are finished up-
domain=portage.config.load_config().default_domain
from portage.package.atom import atom
p = max(domain.repos.match(atom("dev-util/diffball"))) # get the max available
version
b = p.build() # get a build op
b.finalize() # build the sucker
domain.vdbs.add(b)
Is basically what it will be; the nasty stuff required for stable
won't be there, since this is actuall OOP rather then procedural
spaghetti.
May, or may not layer an API over it, although that's something down
the line. Right now working on the v.add chunk.
> > Short term? Unless you're doing questionable stuff like bypassing the
> > cache layer and accessing the files on disk... nope, shouldn't hork
> > anything.
> >
> > ~harring
>
> mostly just lookup stuff, get defaults, status, package info, etc.. All
> emerges are done properly through a terminal and normal command line
> calls.
Yah, nothing that's been talked about should affect querying
interfaces.
~harring
pgpP1xojMdLXM.pgp
Description: PGP signature
Re: [gentoo-portage-dev] portage and porthole
On Thu, 2005-10-11 at 20:51 -0600, Brian Harring wrote: > On Thu, Nov 10, 2005 at 06:42:54PM -0800, Brian wrote: > > Just a quick question. With all the changes I see in this list. Is > > there anything coming (that you know of) that will break porthole's use > > of portage. > Long term? I'm unfortunately looking at breaking pretty much all api > access portage wise, for 3.0. I knew that one. From what I have gathered so far I believe 3.0 is getting the long awaited public API. Is that correct? If so I'll have to start paying more attention to it and setup a test box to start changing our portagelib.py to use it. (I can't afford to trash my main box, I have business stuff on it.) Just let me know when it's time for testing. :) > > Short term? Unless you're doing questionable stuff like bypassing the > cache layer and accessing the files on disk... nope, shouldn't hork > anything. > > ~harring mostly just lookup stuff, get defaults, status, package info, etc.. All emerges are done properly through a terminal and normal command line calls. Thanks... -- Brian <[EMAIL PROTECTED]> -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] portage and porthole
On Thu, Nov 10, 2005 at 06:42:54PM -0800, Brian wrote: > Just a quick question. With all the changes I see in this list. Is > there anything coming (that you know of) that will break porthole's use > of portage. Long term? I'm unfortunately looking at breaking pretty much all api access portage wise, for 3.0. Short term? Unless you're doing questionable stuff like bypassing the cache layer and accessing the files on disk... nope, shouldn't hork anything. ~harring pgpxz1Stqo4LM.pgp Description: PGP signature
[gentoo-portage-dev] portage and porthole
Just a quick question. With all the changes I see in this list. Is there anything coming (that you know of) that will break porthole's use of portage. So far I have not experienced any real difficulties. The only hick-up I had was reloading portage after updating to _rc7. Portage failed to find one of it's modules. Restarting porthole, it was fine. Since this version of porthole is so stable I was going to suggest that it is ready for a stable arch keyword. Of course that will depend on your answer to the above question. cheers :) -- Brian <[EMAIL PROTECTED]> -- gentoo-portage-dev@gentoo.org mailing list
