[arch-projects] Pluggable wrapper

Paul Mattal paul at mattal.com
Tue Aug 31 07:45:06 EDT 2004


>>Basically, if a feature is important enough to write a wrapper for, it's
>>important enough to be in Pacman, most of the time. Prove me wrong, but
>>so far no one has. 
>>
>>SRCPAC is a bit different. All the source management tools in Arch are
>>actually BASH scripts. So writing Srcpac in BASH was a logical step.
>>Unless you plan on integrating ABS/Makepkg into Pacman (don't), keep
>>Srcpac as BASH too (or Python :P).
> 
> 
> I think that's contradictory.  "Anything important enough to write a
> wrapper for should be integrated in pacman." "Srcpac is a wrapper but
> should stay a wrapper."
> 
> srcpac was written in bash because of the simplicity of the functionality
> not because it called other bash scripts.

I recognize this contradiction. I guess what Ben really meant is that 
there's an important set of functionality that should be integrated, and 
things that can be cleanly separated and benefit from being implemented 
as a wrapper can remain that way. I guess I'm not yet sure how I feel 
about that.

>>If you have to run more than one wrapper at once, things have gotten out
>>of hand. That's my opinion. This is where the conflict exists. People
>>like things light, and fear featuritis, but we've seen programs that
>>need a whole mess of things on top just to be useful. This is messy, and
>>it pisses people off. One example is Slackware + all the 3rd party
>>package management tools. Look how many there are. They're not all
>>compatible, and almost all slackware users download them right after
>>installing. If so many people use the features, they should be included
>>by default (though Pat has them on ftp.slackware.com). This "unofficial"
>>requirement has made large, compatible Slackware repositories
>>non-existent. Compare that to Arch, Debian, et al. In fact, many people
>>switch to Arch just for a Slackware + Swaret-like system (I know I and a
>>bunch of people on the IRC channel did).

I definitely agree that things can get too complex and deep, and it is 
one of the reasons I use Arch.. to avoid that.

> 
> 
> But I've heard you yourself say, "you shouldn't write a wrapper for that
> because srcpac is already a wrapper and we won't be able to use both of
> them at once."  Paraphased, obviously.
> 
> The sorts of plugins to this wrapper would be added functionality that
> isn't necessary in pacman but that people bitch about.  I'd rather not have
> a buggy pacman because some guy cried that his package manager didn't skip
> and jump.
> 
> 
>>This will cause issues, because each wrapper is essentially a hack, and
>>it will always be that way until Pacman is made to a library, and the
>>wrappers are written in a Language that can interface directly with C. 
> 
> 
> I hear that a lot too: "A wrapper is a hack, until it uses a library, then
> it's a good idea".  So, how about it's first implemented as a hack, then
> when libpacman is released, the code is modified slightly to be an elegant
> solution?  I figured it'd be written in python... python can do that sort
> of stuff...
> 
> 
>>Wrappers are also unofficial, by definition. You should never have to
>>rely on two wrappers working together, because they are (in theory)
>>written by completely independent people. 
> 
> 
> True, but with a framework and a properly defined API multiple modules
> could work together.  That's the whole point.  You're saying wrappers won't
> work together if they're written by independent people.  Yes, I agree with
> that.  But modules written for a pluggable framework could work together.
> That's why it's a pluggable framework...

I agree with this, Jason. I think that the "module" becomes a "hack" 
when it doesn't follow an API, not because it's written by someone else 
or because it's written in another language.

> 
>>>Enter the pluggable wrapper script.  It would be event based, interfacing
>>>(almost) seamlessly with pacman, and allow you to enabled and disable wrapper
>>>functionality, such as srcpac.
>>
>>Going with my "wrappers are a hack" theory, you're just legitimizing a
>>hack as the official "plugin" system to Pacman. Pacman should eventually
>>allow plugins natively if you really want this. This would probably be
>>the solution to all of our problems, as you choose the features you
>>want.
> 
> 
> I don't think pacman should eventually allow plugins.  There should always
> be a simple way to get to the basics of package management.  I also
> wouldn't want to write pacman plugins in C.  And, to take one of your
> excuses, "suddenly we'd have to install 10 plugins just to get pacman up to
> snuff".

Jason, I don't think your first two statements are mutually exclusive. 
You can have both.

Here's the summary of my input: I agree that having 10 plugin packages 
to install would be annoying; however, just because the program is 
internally structured to use plugins doesn't mean you have to package it 
that way. If it makes sense for stability and simplicity to package the 
plugins into the single pacman package, that's fine.

So I guess my suggestion would be to define a C plugin API, define APIs 
for plugins in other languages where you feel they're necessary 
(structuring it as a "bridge plugin" between that language's plugin API 
and the C plugin API), and then carefully manage the plugins that you 
let into the main source tree. If you wanted, you could structure the 
system so that the list of plugins actually gets compiled into pacman, 
so people *can't* add plugins without distributing a whole new pacman 
package.. which they could still do for testing.

The thorny areas: How do you make sure you've got an interpreter for 
each kind of plugin API? Which languages do you choose as other 
languages for APIs? How do you structure the API to give the right level 
of flexibility?

So all this sounds like a a lot of work, though probably actually less 
than it sounds. Perhaps in the short term, a "wrapper API" might be the 
way to go, as Jason seems to be suggesting. My question is: exactly what 
do you mean by "event driven"? What exactly would be the interface 
between pacman and and the pluggable wrapper script? How would it 
survive changes to pacman itself? How would we keep the pluggable script 
in sync with the current version of pacman?

The really nice part about a plugin structure is that it encourages 
other people to extend pacman, because it will be easier to do so. I 
think ethereal is one of the classic examples of this phenomenon. Then 
the extensions that you like and are stable can be integrated into the 
main tree.

- P




More information about the arch-projects mailing list