Package Manager, how we won't miss thee

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Package Manager, how we won't miss thee
« on June 22nd, 2011, 06:12 PM »
The question about the package manager, SMF mods in general, still haunts us. I recently proposed what I want to do about it to the private board, and now I'd like to expand on that and put it in general terms for everyone; my proposal was more technical than general in nature. Besides, I figure that you want to see not only where we are but a few thoughts and insight into where we're going. (That's what the blog's for, right? :lol:)

SMF's package manager is an interesting artefact, and certainly more than a nod to what came before. But we're bidding it farewell in Wedge, to be replaced with a very different beast, even if it looks similar on the surface.


The Add-on Manager. It sounds nicer than package manager, and it implies its purpose better; packages don't just have to be new functions even in SMF, they can be packs of avatars, language packs and so on, whereas an add-on is physically a new thing added on to the core.

In many ways it's more than just a change of name, it's also a change of mindset: the add-on manager does not allow add-ons to modify files AT ALL. I'm not just removing the functionality from the existing package manager, I'm actually implementing a whole new branch of code to replace it, every aspect is being gutted, torched and rebuilt. It means you're never trying to break old habits, you start out by learning better ones from the word go. It also means that SMF mods will have to be rewritten, but honestly, that's a blessing rather than a curse.

No permissions issues where you have to open up all your files to higher permissions than they needed. You'll even be able to add and remove packages simply by uploading folders and removing them, without risking it just breaking randomly - but you'll have to visit the admin panel to enable it, of course.

It's also much smarter: instead of this version emulate madness and tying it to versions, the process is much closer to feature detection - add-ons declare the facilities they need to be able to use, and if those needs are met, it can be activated. (Add-ons can even, if they so wish, declare that they provide certain facilities, and other add-ons can indicate they want to use them, so you can build add-ons that have implicit dependencies)

Also if a plugin has specific requirements such as obscure PHP extensions, these can be indicated in the package itself preventing installation without them.

Naturally, all this stuff will be available through whatever we come up with as an add-on repository, so it becomes much clearer as to what's needed and what works with what.

Just for an encore, the add-on management will be able to figure out what languages are supported in an add-on, so we can also display that on the add-on repo, as well as displaying it in the core.


Add-ons will live in their own folder, which I expect to call Addons (and removing the old Packages folder), one folder per add-on. That way, a plugin's functionality is self-contained rather than filling up the Sources and Themes/default/languages folders with stuff.

Now, all this sounds wonderful, too good to be true in fact... except it isn't. It's not only workable, but a slimmer, less refined version is even built in to SimpleDesk 2.0 and has been since I prototyped it a year ago. I've learnt some lessons since then, some refinements to that design, and some of the changes we've made in Wedge make it possible to really do it justice.


I won't get into the innards right now, other than that Modifications.*.php files will be disappearing, that the add-ons still use XML to relate their details, much like package-info.xml but nicer, and that it'll have more in common with WordPress' plugins area than SMF's package manager.

I'll release a few more details once I'm comfortable and can show you a bit more about how it works.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Re: Package Manager, how we won't miss thee
« Reply #46, on June 25th, 2011, 12:57 PM »
So you guys plan on releasing full on updates? Hmm since you are going hook-only that makes sense.

And since you plan on having hook registry, then feature detection should be quite enough I believe.

Back to repositories, what do you think of showing all the mods that collide?

Re: Package Manager, how we won't miss thee
« Reply #47, on June 25th, 2011, 01:01 PM »
Quote
So you guys plan on releasing full on updates? Hmm since you are going hook-only that makes sense.
Yup. Much as I hate to keep drawing parallels, it doesn't seem to hurt WordPress. Their updates do just that, though their update bulletin also lists the files that have changed, so you can do comparisons if you want.
Quote
And since you plan on having hook registry, then feature detection should be quite enough I believe.
That's the plan.
Quote
Back to repositories, what do you think of showing all the mods that collide?
Define 'collide'. The whole point is that collisions should be minimised - packages should be able to use the same hooks and operate reasonably independently of each other, at least in theory. What I suspect will be the case is mods end up tripping over themselves where one author hasn't bothered to check that a table is already joined or ends up aliasing a table with an existing alias. Unfortunately we can only go so far in protecting against that...


Re: Package Manager, how we won't miss thee
« Reply #49, on June 25th, 2011, 01:06 PM »
Same add-on to multiple repositories... OK, so assuming we have an add-on with its GUID and version, and it has called upon multiple repos. I think it should indicate the different repos have different versions and it should really let the user make the call as to which one they want to get it from and what version.

It should display the highest available version from each repo primarily but can state all versions that it has available.

Multiple repos hosting the same add-on isn't a blocker to the concept of doing it, just that it has to be handled in a sane way on both the client and server.