On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
> Given the following:
> # qlist -Iv sys-apps/portage
> sys-apps/portage-2.1.4.5
>
> How do I safely extract the "2.1.4.5"?
>
> (I don't necessarily need to use qlist. Just want to get the version of an
> installed package within a bash script)

This *really* should be folded into portageq offhand- it's the initial
step towards shifting versionator logic (yet another standalone
parser/comparison implementation) into the PM.

Counter arguements?
~brian

On Tue, 2008-11-25 at 18:05 +0200, Amit Dor-Shifer wrote:
> Given the following:
> # qlist -Iv sys-apps/portage
> sys-apps/portage-2.1.4.5
>
> How do I safely extract the "2.1.4.5"?
>
> (I don't necessarily need to use qlist. Just want to get the version of
> an installed package within a bash script)
>


qatom $(qlist -ICv sys-apps/portage) | awk '{print $3}'



--
Ned Ludd <solar@gentoo.org>
Gentoo Linux

On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote:
> On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
> > Given the following:
> > # qlist -Iv sys-apps/portage
> > sys-apps/portage-2.1.4.5
> >
> > How do I safely extract the "2.1.4.5"?
> >
> > (I don't necessarily need to use qlist. Just want to get the version of an
> > installed package within a bash script)
>
> This *really* should be folded into portageq offhand- it's the initial
> step towards shifting versionator logic (yet another standalone
> parser/comparison implementation) into the PM.
>
> Counter arguements?
> ~brian

Yes. he said a bash script. portageq still takes a few seconds to load
and invokes far far to many instructions for very simple info.

The 3 execve's I just posted are still faster than one portageq call.
So.. foo.c wins again.




--
Ned Ludd <solar@gentoo.org>
Gentoo Linux

On Tue, Nov 25, 2008 at 04:18:22PM -0800, Ned Ludd wrote:
>
> On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote:
> > On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
> > > Given the following:
> > > # qlist -Iv sys-apps/portage
> > > sys-apps/portage-2.1.4.5
> > >
> > > How do I safely extract the "2.1.4.5"?
> > >
> > > (I don't necessarily need to use qlist. Just want to get the version of an
> > > installed package within a bash script)
> >
> > This *really* should be folded into portageq offhand- it's the initial
> > step towards shifting versionator logic (yet another standalone
> > parser/comparison implementation) into the PM.
> >
> > Counter arguements?
> > ~brian
>
> Yes. he said a bash script. portageq still takes a few seconds to load
> and invokes far far to many instructions for very simple info.
>
> The 3 execve's I just posted are still faster than one portageq call.
> So.. foo.c wins again.

Curious, does qatom handle use deps? Slot deps? Plans to add
repository deps (admittedly they've not landed)?

The point of shifting it into portageq isn't speed based; it's to
transfer responsibility for atom parsing from multiple authorities
into a single one.

Besides, just because portageq is slow for heavy data ops doesn't mean
it's going to be slow for doing simple atom splitting. Quick test
locally, cold cache pegs it at 3s- with minor use of snakeoil
demandload that's likely halvable.

~brian

On Tue, 2008-11-25 at 16:31 -0800, Brian Harring wrote:
> On Tue, Nov 25, 2008 at 04:18:22PM -0800, Ned Ludd wrote:
> >
> > On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote:
> > > On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
> > > > Given the following:
> > > > # qlist -Iv sys-apps/portage
> > > > sys-apps/portage-2.1.4.5
> > > >
> > > > How do I safely extract the "2.1.4.5"?
> > > >
> > > > (I don't necessarily need to use qlist. Just want to get the version of an
> > > > installed package within a bash script)
> > >
> > > This *really* should be folded into portageq offhand- it's the initial
> > > step towards shifting versionator logic (yet another standalone
> > > parser/comparison implementation) into the PM.
> > >
> > > Counter arguements?
> > > ~brian
> >
> > Yes. he said a bash script. portageq still takes a few seconds to load
> > and invokes far far to many instructions for very simple info.
> >
> > The 3 execve's I just posted are still faster than one portageq call.
> > So.. foo.c wins again.
>
> Curious, does qatom handle use deps? Slot deps? Plans to add
> repository deps (admittedly they've not landed)?

Nope. I'm sticking with EAPI=0 behaviorism's and the development of
those utils has pretty much stopped. Well I did slip in some :slot
handling a little while ago due to the syntax of the world file changing
a while back after being annoyed.

> The point of shifting it into portageq isn't speed based; it's to
> transfer responsibility for atom parsing from multiple authorities
> into a single one.

It's still a good idea to expend the functionality of portageq. But for
scripting from bash, reality wins as most everything python-portage
related falls a little short due to the sheer number of file i/o calls
python makes looking for files that might not pertain at all to the info
the user is after. Granted today it's a heck of a lot faster than it
used to be a few years ago when the loading problem was first noticed.

> Besides, just because portageq is slow for heavy data ops doesn't mean
> it's going to be slow for doing simple atom splitting. Quick test
> locally, cold cache pegs it at 3s- with minor use of snakeoil
> demandload that's likely halvable.
>
> ~brian


I'm all in favor of using the right tool for the task at hand whatever
that may be.

On Tue, Nov 25, 2008 at 08:54:29PM -0800, Zac Medico wrote:
> Ned Ludd wrote:
> > On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote:
> >> On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
> >>> Given the following:
> >>> # qlist -Iv sys-apps/portage
> >>> sys-apps/portage-2.1.4.5
> >>>
> >>> How do I safely extract the "2.1.4.5"?
> >>>
> >>> (I don't necessarily need to use qlist. Just want to get the version of an
> >>> installed package within a bash script)
> >> This *really* should be folded into portageq offhand- it's the initial
> >> step towards shifting versionator logic (yet another standalone
> >> parser/comparison implementation) into the PM.
> >>
> >> Counter arguements?
> >> ~brian
> >
> > Yes. he said a bash script. portageq still takes a few seconds to load
> > and invokes far far to many instructions for very simple info.
> >
> > The 3 execve's I just posted are still faster than one portageq call.
> > So.. foo.c wins again.
>
> Well, I think portageq will be fine if it's limited to a small
> number of calls. Here's a simple test, with portage-2.2_rc16:
>
> # time python -c "import portage.versions"
>
> real 0m0.141s
> user 0m0.124s
> sys 0m0.016s
>
> It's not so bad if it only has to be called a few times. For cases
> where a large number need to be split, they could be processed in a
> batch by a single portageq call, by either passing all the inputs in
> as arguments or writing them to stdin.

So.. eapi3 meanwhile?
~brian