Re: [gentoo-portage-dev] [PATCH] BinpkgExtractorAsync: xz and gzip decompression (142579)

[Brian Dolbec]

On Thu, 15 Jan 2015 20:53:02 -0800
Zac Medico <zmedico@g.o> wrote:

> On 01/15/2015 07:00 PM, Brian Dolbec wrote:
> > On Thu, 15 Jan 2015 17:27:23 -0800
> > Zac Medico <zmedico@g.o> wrote:
> >>  		# Add -q to bzip2 opts, in order to avoid
> >> "trailing garbage after # EOF ignored" warning messages due to
> >> xpak trailer.
> >> +		if comp == "bzip2":
> >> +			decomp_cmd =
> >> "${PORTAGE_BUNZIP2_COMMAND:-${PORTAGE_BZIP2_COMMAND} -d}"
> >> +		elif comp == "xz":
> >> +			decomp_cmd = "xz -d"
> >> +		elif comp == "gzip":
> >> +			decomp_cmd = "gzip -d"
> >> +		else:
> >> +			raise AssertionError("Unexpected
> >
> > No offense, but yuk to the if foo .... else bar... else...
>
> It's simple and it works. Why don't we just go with this simple
> approach first, and add fancy stuff later on?
>

PORTAGE_COMPRESSORS = {
    "bzip2": "${PORTAGE_BUNZIP2_COMMAND:-${PORTAGE_BZIP2_COMMAND} -d}",
    "xz": "xz -d",
    "gzip": "gzip -d",
    }

try:
    decomp_cmd = PORTAGE_COMPRESSORS[comp]
except: AtributeError:
    writemsg("You fool we don't support the %s (de)compression type!)



makes it simple to add new types, saves mile long if, elif, elif, else
code ;) There is also a good chance the code won't need editing to add
a new type, just add it to the dict definition. Second advantage is the
code should be slightly faster. (yes, I realize this isn't in a
multi k iteration loop, so speed-up is minuscule) but portage can't
afford to waste many cycles ;)  it all adds up...

P.S. I don't expect you to use the writemsg(...) as is :D


 
> > I already have code that does this much better, I decided I was
> > going to release it separately from catalyst because it is
> > generally useful and in many ways more future proof.  I know you
> > were interested in it, but I hadn't gotten around to establishing
> > it in a separate repo.  I also didn't know you were already working
> > on this.
> >
> > I've attached it to this email for you to look over.  It needs a
> > bit of work for an independent release, but it is easily extended
> > with configuration changes.  It can also be easily extended with
> > custom commands if needed.
> >
> > If you are interested, it would not take long to have it release
> > worthy and in the tree.
>
> I am interested in your library, but it does much more than is needed
> in BinpkgExtractorAsync.The requirements are:
>
> 1) Map bzip2, xz, or gzip to an appropriate decompression command. The
> command should be guaranteed to support -c and -q options, since
> BinpkgExtractorAsync relies on them.
>
> 2) Respect the user's PORTAGE_BUNZIP2_COMMAND and
> PORTAGE_BZIP2_COMMAND variables.

yes, I know there is more there than is needed and a few options need
adding.

-- 
Brian Dolbec <dolsen>