[arch-projects] Pluggable wrapper

[Jason Chu]

On Mon, Aug 30, 2004 at 11:54:46PM -0500, Ben Mazer wrote:
> On Mon, 2004-08-30 at 14:55, Jason Chu wrote:
> > There are two conflicting schools of thought with respect to adding
> > features to pacman:
> > - everything should be written into pacman, because there's less to worry
> > about that way
> > - everything should be a wrapper, because it complicates pacman less
> 
> Actually, three schools of thought. This would be mine:
>   - some things should be in a wrapper, some things should be in pacman
> 
> Almost everything I've seen brought up so far I thought should go in
> Pacman. Now you know me, I like things light. But most of the features
> are important enough to be in pacman proper. For example, I think
> rollbacks and orphans should be in pacman. 
> 
> 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.

> > There is a related issue to wrappers though: if you have more than one
> > wrapper that do complimentary things, shouldn't you be able to run both of
> > them at the same time?
> 
> 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). 

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

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

> Of course Pacman couldn't be a plugin/library interface for a very long
> time, but I'm saying this is a bad road. I guarantee you that if you
> make a wrapper framework and begin writing lots of wrappers, this "hack"
> will become permanent, and cause innumerable issues (the slackware
> example again). 

I believe you wanted to use the auxiliary verb "can't", "couldn't" meant
that it'd only be a plugin/library interface for a short time.

You wouldn't be writing lots of wrappers, you'd be writing lots of modules.

I don't see how the slackware example fits here.  We're not talking about
different package managers and different repos.  We're talking about added
functionality.

> > My two example cases were srcpac and rollbacks.  Rollbacks could be
> > implementable through such a system, but I'm already told it'll be going
> > right into pacman itself.  Another example is regular expression searching.
> 
> I've already stated other places that I think RegExps should be in the
> pacman proper (if they're deemed worthy enough). Why? Because they
> conflict with an existent Pacman feature (Search). Now instead of just
> adding features, you're going to modify existing ones? This could become
> like Perl, with Wrapper dependency hell. Wrappers will start to
> implement "essential" features, so wrappers will depend on one another.
> Then you'll need 10 wrappers working together just to get Pacman up to
> suff. 

Conflict with features?  Did you look at how it was implemented originally?
He added a new arg to pacman.  -Sx would search using regular expressions.

The idea is never to implement an "essential" feature with a wrapper.  If
regexps aren't deemed worthy enough, then do they go the way of the dodo?
Do we just ignore them because they're not pure enough to go into pacman
proper?

I never said things that should go into pacman would go into a module
instead.  I'm saying things that don't need to go into pacman could be in a
module instead.

> > What does everyone think of this idea?  Is there enough demand for
> > different functionalities that would be nice for some people but annoying,
> > problematic or just stupid to add to pacman?
> 
> Plugins would be nice. Do it right or don't do it at all (:P). But like
> I said, most of the requested features I like, and think should go into
> pacman. The others I think shouldn't happen in any form. I do think
> Srcpac should eventually become part of the default Pacman distribution,
> just like Makepkg/ABS. 

"right" is a relative term at this point.  I don't disagree that most of
the requested features probably should go into pacman, but there are others
that don't need to.

Why is srcpac an exception this whole time?  I don't see how you can say,
"wrappers are evil and should never exist! but I love my srcpac!"

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/20040830/bd22c747/attachment.pgp>