Wedge

Public area => Development blog => Topic started by: Arantor on June 22nd, 2011, 06:12 PM

Title: Package Manager, how we won't miss thee
Post by: Arantor 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.
Title: Re: Package Manager, how we won't miss thee
Post by: Dr. Deejay on June 22nd, 2011, 06:20 PM
Nice post Arantor :)
Title: Re: Package Manager, how we won't miss thee
Post by: RvG on June 22nd, 2011, 06:23 PM
Too much tease eh... any sample pic? :P
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 22nd, 2011, 06:48 PM
The awesome in this astonishes me. A lot like Drupal, eh?

I'd love to hear more about it. I'm not a great developer but reading about this made me want to dive into it.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 22nd, 2011, 07:20 PM
Quote from RvG on June 22nd, 2011, 06:23 PM
Too much tease eh... any sample pic? :P
No picture since I'm still working on the internals, but it's not exactly pretty ;)

Yes, a bit like Drupal, just not nearly so anal-retentive. Developing for Drupal isn't so much a hobby, more somewhere between a career and a vocation.
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 22nd, 2011, 07:27 PM
I just noticed that your blog shows the earliest post at top. Might want to do something about that (so people see the newest news first):

http://wedge.org/blog/

Or am I missing something?  :angel:
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 22nd, 2011, 07:30 PM
Odd, so it does, how odd.
Title: Re: Package Manager, how we won't miss thee
Post by: Dragooon on June 22nd, 2011, 07:42 PM
I love the sound of this, good luck! :)
Title: Re: Package Manager, how we won't miss thee
Post by: Nao on June 22nd, 2011, 07:43 PM
Quote from RvG on June 22nd, 2011, 06:23 PM
Too much tease eh... any sample pic? :P
Even I don't get to see a preview, eheh ;)
But I trust that Pete will impress us once again. I always found it too bad that his skills were applied to a mod that has a relatively niche target (SimpleDesk), so it's great to see that whatever Pete developed in his time on SD can be of benefit to Wedge as well :)

Oh, BTW, Pete calls them Add-ons but I insist on "Extensions" in the French versions, and "plugins" or "mods" in my casual English posts. Don't bother, it's just that I'm not much into the word "Add-ons", but for what it's worth, it could be called "Rectums" that I wouldn't mind, as long as it's just great :P
Title: Re: Package Manager, how we won't miss thee
Post by: Nao on June 22nd, 2011, 07:48 PM
Quote from Arantor on June 22nd, 2011, 07:30 PM
Odd, so it does, how odd.
Hmm, I hardcoded the order to be chronological when I created the Feature blogs.
Technically, it seemed like the best way to do it.

I added an 'exception' to the Dev Blog, so it should work now.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 23rd, 2011, 12:08 AM
Yes, I poured an awful lot of time into SD, because my own needs needed it, but I learned a very large number of lessons from it, and all of the add-ons design is emerging either directly out of SD code, or things I learned from it.

When I get back to my desktop, I'll upload a screenshot from SD's plugin manager which is the closest to a preview that I can give; right now figuring out all the mechanics was more important.
Title: Re: Package Manager, how we won't miss thee
Post by: DoctorMalboro on June 23rd, 2011, 12:54 AM
Will the plugins/themes be approved in a time of... less than 3 years?
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 23rd, 2011, 01:09 AM
That's to be decided when we get round to building a plugin repository.
Title: Re: Package Manager, how we won't miss thee
Post by: Nao on June 24th, 2011, 12:49 AM
I see us relying on the community to rate new plugins. So. Immediate release. Wordpress-like.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 12:50 AM
If we're going to do that, are we going to do the whole shebang, of giving users an SVN repo to put their plugins in and be auto-built from that?
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 24th, 2011, 01:01 AM
It would be nice if the plugin repo was a bit better laid out than the SMF one.

If I'm being vague it's because there are a lot of problems with it as it is currently. x]

EDIT: One thing that could be done better is search with multiple factors, tags.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 01:07 AM
Yeah, I had no intention of mimicking it, so many ways it can be improved upon it isn't funny.
Posted: June 24th, 2011, 01:03 AM

OK, I promised a copy of SimpleDesk's plugin screen, and something based on this is what's being built into Wedge. Imagine this hybridised with MyBB's and WordPress's and made less fugly at the same time.
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 24th, 2011, 01:12 AM
Looks a lot like the "Core Features" page! (I'm not implying that it is at all the same thing, but it does.)

One thing I noticed that is unintuitive with the "Core Features" page is that when you press one of the buttons to make it "On", you assume that it's turned on, and go on to another page, while indeed, you have forgotten to save! I was fumbling around a bit when I tried turning on Advanced Profile Fields and didn't understand why it didn't actually activate when I had clicked it a few times. :)
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 01:15 AM
Quote
Looks a lot like the "Core Features" page! (I'm not implying that it is at all the same thing, but it does.)
I can't imagine why ;) Yes, when I wrote that one a year ago I shamelessly ripped it off from Core Features. And it still suffers from the same unintuitive behaviour that Core Features does. This is, amongst other things, one of the lessons I learned since building this originally.
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 24th, 2011, 01:18 AM
A simple band-aid fix could be replacing the power icons with checkboxes. People are used to submitting those.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 01:25 AM
Even simpler... just turn off Javascript. There's actually an entire non-JS workaround implemented but I doubt anyone's ever seen it.

But this is one band-aid that I daren't add. Either this is done, fully, or we don't bother with it at all and leave it as it is - there's actually no room on this one for band-aids.
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 24th, 2011, 01:36 AM
Well, just replacing the image with an image of a checkbox will make it like 50% more intuitive and won't make a lick-a difference otherwise. But I do agree that something done right is better than something done halfway.

Like this:

(http://i.imgur.com/bldlg.png)
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 01:39 AM
Oh, definitely, I'll agree with that. But this is the sort of thing where we have the opportunity to break from years of established behaviour and I'm going to grab it with both hands :D

(Btw, Core Features will be beaten into submission and removed at some point.)
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 24th, 2011, 01:53 AM
I don't think I'll miss it much. Again i have to come back to Drupal, where a lot of what is here called core features are modules, like, on fairly even level with other "plugins". This seems to me to be a very good system.

(Hehe, sorry for constantly mentioning it, but this conversation really reminds me of it. Here's why:)

(http://i.imgur.com/nEx0q.png)

(Ignore the random text marking.)
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 01:55 AM
I am not going to use checkboxes. It does not work structurally or logically for the processes required by Wedge.
Title: Re: Package Manager, how we won't miss thee
Post by: Norodo on June 24th, 2011, 01:58 AM
Quote from Arantor on June 24th, 2011, 01:55 AM
I am not going to use checkboxes. It does not work structurally or logically for the processes required by Wedge.
Hehe, now you're just making me more curious. ;)

But I'm sure you have a good idea of what you're doing. At least from your other ideas and posts your head seems screwed on right.
Title: Re: Package Manager, how we won't miss thee
Post by: live627 on June 24th, 2011, 06:29 AM
Heads have screws? Oh, you mean the neck... :P
Title: Re: Package Manager, how we won't miss thee
Post by: Nao on June 24th, 2011, 11:00 AM
Re: plugin repo -- it will be based off Aeva Media (well, the Wedge Media component, technically.) Any features I will write to make it behave more like a plugin repo will be available in Wedge as well, either as core, or as a plugin. As for SMF's plugin repo, I don't think it would take me more than a couple of days to build something that's actually better than theirs...

Re: core features page. The Save button is also something I totally missed the first times. I completely agree that it's a big usability mistake. I didn't touch it because I figured most people would be used to it by now. However, now that I see I'm not the only one -- I guess it needs to be changed. But Pete already has plans about this so I'll leave it up to him... :)
(Also, the checkbox stuff shows up on first page load when you go there. Just for a second or two...)
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 11:08 AM
The biggest thing that a plugin repo needs to be able to do is harvest the meta data from the XML file in the package and process it. The reality is that whatever process there is for publishing a package (be that upload, or build from SVN or similar, or whatever), that just has to process the XML and display that information alongside the download.
Title: Re: Package Manager, how we won't miss thee
Post by: Dragooon on June 24th, 2011, 11:16 AM
Since you are working on Package Manager, perhaps also add something like dependency to other packages in the repository or package itself, similar to linux's repositories. Can come in handy.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 11:25 AM
Actually, there is, and I did mention it before, at least what I thought of doing.

Since the very idea of versioning is... awkward... I thought of something closer to home, so to speak.

An add-on's manifest file states what hooks it requires in order to work, plus it indicates what functions are required in order for it to work. (It also has the facility to demand a PHP and MySQL version if that's relevant, e.g. MySQL 4.1.2 is currently the minimum but I have a plugin where I explicitly need MySQL 5.0.3. Unlike other things, there are different behaviours between PHP and MySQL versions that you can't necessarily validate through testing existences of things)

There's also the facility for an add-on to indicate that it provides new hooks, too. That gives you an implication of dependency but not based around versions, but facilities made available.

While yes, I could build in version requirements, I find them more a hindrance than a help - the best example I have for this is SMF itself, with mods stating versions that they are compatible with, rather than whether they are actually compatible without having to update just to patch a version number.
Title: Re: Package Manager, how we won't miss thee
Post by: snoopy-virtual on June 24th, 2011, 12:19 PM
Another thing I never liked from the SMF Package Manager is it never tells you if your mods are up-to-date or if any of them has been upgraded and you missed it.

Normally when you open your Package Manager you see all your mods with a green light and you could think all of them are up-to-date. It happened to me at the beginning until I noticed I had to subscribe to receive notifications of updates of the mods I was interested in.

Are you planning to change that?
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 01:04 PM
That's less a fault of the package manager and more a fault of the package serving architecture.

WP has this function, however, WP has it set up so that you are pretty much obligated to use their architecture for grabbing plugins. Consequently, if you're using their architecture you can use it to keep up to date. But the minute you start having any (and I do literally mean *any*) other service, you're pretty much telling users they have to keep things up to date themselves, as one of the caveats of not using the core architecture.

Now, I'm not exactly enthusiastic about having a single locked-in repo. Partly because of all the arguments about the 'walled garden' (personally, I'm not against it since it benefits users but it doesn't help developers much if those in control of the garden change the ruels)

But without a single master repo - and everything else being 'caveat user', so to speak - there's no really good, or reliable, way to manage that kind of update.
Title: Re: Package Manager, how we won't miss thee
Post by: billy2 on June 24th, 2011, 01:24 PM
Sorry to butt in........


If your idea doesn't give every SM forum admin a stiffy (male OR female) Ill make a big donation to your hosting..... well £50 anyway :)

Billy
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 01:48 PM
OK, I'll say it again. And I'll be more blunt about it.

I WILL NOT BUILD A WALLED GARDEN. I will not create an environment that forces a single source of mod production.

There are two reasons for this:
1. I did actually design and build my own mod repository for SMF once upon a time, where I could publish what I wanted without any restrictions imposed by any moral majority. I could, for example, have released a mod that allowed for viewing user PMs, if I so chose. Such a mod would have been forbidden by SMF, but the only rules I set for my site were my own. I would be trampling on the very freedom that Wedge was borne out of if I did not allow for choice.

2. Wedge opens a lot of doors, it represents a shift from the past. One of the things I was never happy about with SMF was its lack of premium resources.

The health of an ecosystem is reflected in the community that grows up around it. While I dislike much about WordPress, I respect that it has a lot of contributions from its community, in the form of themes and plugins, and there is a goodly number of premium resources. The platform is considered sufficiently viable that professionals are contributing to it, that it doesn't just represent a loose-knit collection of individuals contributing in their spare time and augmenting it with those who can justify spending professional-grade time and energy contributing to the ecosystem.

My stance is just that: if a platform and its ecosystem actively discourages professional-grade users from publishing premium resources, the sum total of its ecosystem becomes a collection of hobby contributors producing hobby contributions.

This is not, and should not be, construed as an insult to hobby authors - people just contributing code when they feel like it, is the backbone of any software-related community. But there is a glass ceiling of sorts: those who do it as a hobby invariably do not have the time and energy to commit to contributions in the same way paid professionals can do so. Being a hobby, they may not pursue the finer points of programming, and as such it's likely that - objectively speaking - the quality will be lower.

I should note that this isn't true of all ecosystems, nor is it true of all hobbyist programmers vs premium programmers. There are genius hobbyist programmers out there, just as there are absolutely abysmal premium programmers out there. But as a broad rule, if charging for something, the quality curve tends to be higher.

I do not want to design an environment that casts out the premium contributions. If it were true that people valued price over performance, we'd all be using SMF/phpBB/etc and no-one would be using vBulletin or IPB - because they are paid endeavours, there is much more incentive for them to keep developing, plus more incentive for them to add new things, because there's a reward in it other than the pure satisfaction of the thing.

That's another thing that's quite important: the reason *why* people do it. We're up front about why we're doing Wedge: because we're building it to be the platform we want it to be. When I wrote mods, I wrote them because they fulfilled a task I needed of them - but that was it. I didn't want to be dragged into ever-increasing circles of more features just because people asked me to - there was less joy in doing that, and I wrote things to work how I wanted them to, and I've lost count of the number of times I was asked to change what I did because it didn't suit someone else - if I wanted it to work the way they wanted, I'd have written it like that up front.

Paid contributions to the ecosystem actually swing the balance towards users, rather than leaving the power solely in the hands of the developer in their spare time: if there's a demand for a certain function/feature, it'll be written and if the market can stand it being charged for, market economics will allow it to.

There is an implied third reason that sums up the two together: us running a plugin repository that handles paid plugins puts responsibility on us. It brings up who is responsible for payments, who is responsible for security matters, and potentially would put us in legal liability situations that we have no desire to get into in the first place. This is why I didn't end up running smfmarketplace.com as I once envisaged.

Consequently, having an 'official repo' like sm.org has is nice but it removes the potential for premium resources and tying users into it brings a whole world of hassle in terms of walled garden. The last thing I want to do is shoot developers in the foot who like Wedge as a platform but may not care for myself or Nao in terms of personality (hey, it happens, we are perhaps 'abrasive' people)

That all said, I'm inclined to keep package servers in some form or another, but not necessarily updating magically. Any plugin that really needs it (like SimpleDesk, SimplePortal etc.) can implement their own method readily enough.
Title: Re: Package Manager, how we won't miss thee
Post by: Rustybarnacle on June 24th, 2011, 10:30 PM
Would it be considered a walled garden if you went Cydia style?  This would allow Wedge forums to check your repository for updates as well as mine if I were to build one and then let the community know I had a repository that was automagically compatible with Wedge and all they had to do was point their forum at my repository.

Not that I have those skills but for others.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 24th, 2011, 10:35 PM
What happens, then, if the same plugin is in two different repositories? Which one should be used? Should I have to track where it's come from? What happens if you install it manually (which is possible), how should it phone home then?

I have already spent quite a bit of time thinking about this, I'd already long considered Cydia style too - but because you're getting it via the store in the first place, there is a mechanism for tracking from its source.

It still doesn't solve the issue of paid repositories, either.
Title: Re: Package Manager, how we won't miss thee
Post by: Nao on June 24th, 2011, 11:43 PM
Quote from Arantor on June 24th, 2011, 01:48 PM
I WILL NOT BUILD A WALLED GARDEN.
Don't worry, I'll do it for you. :niark:
Title: Re: Package Manager, how we won't miss thee
Post by: Rustybarnacle on June 25th, 2011, 06:27 AM
My thoughts here, and not pushing anything I'm just brainstorming a little so if you've already discarded this or don't wanna talk about it anymore you can tell me to shut up already.  :)

If its built to check whatever repository the forum owner has pointed it to, then it can check all repositories for version numbers and update from anywhere that has an approved package in that repository.  Really, most people with other repositories won't be mirroring you, they'll be doing their own thing for their own projects both paid and free that they want control over.  If they want a paid option then they can figure out access to paid repositories or you can use group level access where paid members go into a group with access to paid repositories or whatever.

Like I said though, I'll shut up if you don't want to think about this any more.  I was just enjoying thinking out something that didn't involve a diaper.  :)
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 25th, 2011, 10:11 AM
Quote
Really, most people with other repositories won't be mirroring you
You'd think so, but the reality does not bear that out. The repository of mods on SMF Hacks.com contains a surprising number of duplications between that and sm.org's repository. That said, the number of package servers for SMF is rather small and doesn't really work that well... off the top of my head the only package servers I can think of, in total:

* sm.org's own
* SMF Hacks.com
* the one I used to run
* Niko runs servers for his projects, one per project I believe
* SimpleDesk has one

And even there was duplication. I already mentioned SMF Hacks, mine had updated versions of some already on sm.org, and SimpleDesk's serves SD plus mods that were contributed by the team as a whole, all of which are on sm.org too.
Quote
Like I said though, I'll shut up if you don't want to think about this any more.
It's not about that - it's simply that I've been over this ground a lot and haven't found any solutions that tick all the boxes, so to speak.


That said, in amongst the headache pain of the last day or so, I did have one idea about how it might work, including even paid stuff, just need to make sure it's provided for in the system, and interestingly it does follow the same sort of idea: instead of doing the Cydia thing and tracking where it comes from, have a package identify itself with a unique ID (which, of course, relies on packages actually pushing a unique ID in the XML, but that's another matter), and query the servers for the packages they hold, matching against that unique ID and version number.

I realised that while I'd included an SMF-style ident in the package, it's not actively being used for anything so I'd be better off using a GUID instead there which for all intents and purposes would be unique and could then be trusted to be used to track whether a given package is available on a given server.

As for paid repositories, certain things hold true with those: most notably that it's done by access groups on a forum. All we do is provide the username and password - suitably hashed, of course - as part of the query. If anything I'd probably make a package server respond to an XML-RPC query rather than just shoving a massive XML file (hint: when you do the browse thing on sm.org, the packages.xml file is served up and processed in your server... last I checked, that topped 1.1MB of XML)
Title: Re: Package Manager, how we won't miss thee
Post by: Nao on June 25th, 2011, 10:53 AM
Suggestion. Maybe already done.
Have packages put into their XML the URL to either the official package or another XML with the URL and version number.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 25th, 2011, 11:06 AM
The XML already has the version and name (which it requires), and provides space for the author and the author's site, but rather avoid putting call-home links like that in the package.

While I don't want to limit people making package servers if they want, I am slightly hesitant to encourage the world and his dog to make one, which is principally the problem I see with the Cydia model, you'd end up with mods so fragmented rather than sane distribution methods.

The XML having a GUID and version number means it has some concept of self-awareness (i.e. I am <big long identifier that's unique to me>) and that can be used to query the servers that a given install is about. I'm not averse to a package being able to indicate package servers though.

(And, at the end of all this, I get to remove an SMF table, yay!)
Title: Re: Package Manager, how we won't miss thee
Post by: Dragooon on June 25th, 2011, 11:12 AM
Okay, please do not drop version detection entirely. Make it important to have versions, because many times feature detection itself isn't enough. Because one cannot detect a specific version of a mod depending upon feature(It may have same features, but different hooks), or their may be an important bug fix required for the add-on which is based on version detection.

And if a mod has multiple versions in multiple repositories, just show all of them(Highest version first). Simple as that, do not make it important to have a repository hosted mod but please push the repositories to be functional and mainstream. Cydia does handle paid mods and it works quite nicely, one just needs an auth to get in.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 25th, 2011, 11:26 AM
There is version detection for PHP and MySQL for this exact reason because you can't always validate functionality by existence of given functions there, but I don't see why you need to do version detection otherwise: if a mod provides hooks x and y, competent developers will keep the hooks working the same way other than bug fixes between versions - that's the whole point of having an API by definition, and the whole point is that it should be reasonably abstract, the calling code shouldn't have to worry about the exact definition provided that the API signature is the same.

In all honesty I don't expect many mods to offer hooks anyway.

Give me an actual example, not a contrived one, that validates this point and I'll tweak it but I'm really, really not wanting to go down that road if I can help it: one of the greatest weaknesses of SMF is that mods have version number dependencies when they really shouldn't have it - how many mods exist for 1.1.x that will work on all versions of 1.1.x but because the author hasn't updated the version number, leading to "can someone update this for 1.1.14?" posts? Far, far too many - and I'd rather get away from doing it.

From my perspective, if a mod author is smart enough to be writing their own hooks, they're probably smart enough to figure out how to write version-free code.
Title: Re: Package Manager, how we won't miss thee
Post by: Dragooon on June 25th, 2011, 11:28 AM
Will you be registering the hooks that a mod calls for validation purposes?
Posted: June 25th, 2011, 11:28 AM

Oh and do you plan on providing delta updates?
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor on June 25th, 2011, 11:53 AM
Quote
Will you be registering the hooks that a mod calls for validation purposes?
Yes, plus the hooks that a given mod provides.
Quote
Oh and do you plan on providing delta updates?
You mean like SMF's 1.1.13 -> 1.1.14 patches? Probably not. (WordPress doesn't and their mods don't exactly do version checking either.)
Title: Re: Package Manager, how we won't miss thee
Post by: Dragooon 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?
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor 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...
Title: Re: Package Manager, how we won't miss thee
Post by: Dragooon on June 25th, 2011, 01:02 PM
By collisions I was referring to same add-on to multiple repositories.
Title: Re: Package Manager, how we won't miss thee
Post by: Arantor 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.
Title: Re: Package Manager, how we won't miss thee
Post by: Dragooon on June 25th, 2011, 01:13 PM
Okay, great.