[arch-projects] Pluggable wrapper

[Jason Chu]

> >>>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.

I'm pretty sure the plugins for other languages point is a sticky one... we
don't want to have pacman compiling in a python interpreter just to use
some plugins.

Though I do like the idea of being able to statically, at compile time,
define your list of plugins to be shipped.  That's kinda cool.

> 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?

Those are the tough questions.  I already answered one by saying that
building an interpreter into pacman is not an acceptable option.  That
still leaves options like pyrex though.

The API is an even more difficult problem.  I only have a vague idea.

So then, if you were a plugin API for a package manager, what would you
look like?

> 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?

It would be event driven because each module that wanted in would register
itself to receive different events in the pacman process.

If you look at how srcpac wraps pacman, srcpac becomes a command of itself.
It only calls pacman when it needs to.  The design of srcpac allows it to
ignore any functionality that doesn't affect its own functionality.

Any groundbreaking changes with pacman would need an upgrade to the wrapper
framework.

> 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.

I've never looked at the ethereal plugin system ;)

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.

My old gpg key expired, the new one is available from keyservers.  I was
stupid enough not to realize this before it was too late, so I am not
able to sign my new key with my old key.  If this assurance isn't enough,
please contact me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-projects/attachments/20040831/5e209aba/attachment.pgp>