On Applications, Plugins and Packages
I am having a bizarre discussion on the git mailing list about whether it is ok for an application (git, say) to provide its own plugin installation command.
E.g.:
git install gitwork.
The idea has been described as 'horrid', 'utterly horrid' and 'crap'.
Bizarre.
The concept of a division of responsibilities between 3 roles seems to be misunderstood.
There are 3 roles:
application, plugin and package.
- The application provides the plugin manager.
- The distribution provides the package manager.
- The package manager packages the plugin as a OS-specific package.
- The package manager installs the package, containing the plugin.
- The package manager calls the application's plugin manager to activate the plugin
Optionally, the application delegates plugin installation request to one or more package managers.
Simple, isn't it?
Yes, Ruby got it wrong. Why did it get it wrong?
ruby got it wrong because ruby has a plugin manager (gem) that wants to be a package manager.
Just because Ruby got it wrong, doesn't mean git can't get it right and be a better platform for it.
posted by Jon Seymour at 15:09
2 Comments:
Your idea seems reasonable.
It's nothing more complicated than, say, a debian package which installs a website under apache using the "a2ensite" command to enable the site, rather than doing all the same low-level operations to achieve the same result.
How is this different from "perl -MCPAN -e shell" ?
Well, I think it should be better.
As I understand it, Perl doesn't separate the responsibilities of package manager and plugin manager - CPAN does both. I think this more or less means that CPAN needs to be quite aware of the details of lots of different platforms.
In my proposal, package managers get a chance to deal with platform-specific build concerns and dependency management.
Once the package is built, the git plugin manager gets a chance to activate it and do git-specific validations and activation.
The git plugin manager has considerably reduced responsibilities. It doesn't know about distribution or OS concerns, and definitely doesn't have the first clue about how to build stuff, other than by delegation to a platform package manager.
It just knows how to manage the activation state of git-plugins, which is a pretty limited scope.
Of course, if your package manager doesn't know about the plugin, the build solution reduces to the same solution as CPAN, where the plugins own build script gets invoked which may or may not work depending on how well configured your dependencies happen to be.
That said, I am not really a huge expert on CPAN, so perhaps I have some details wrong.
Post a Comment
<< Home