AddOn Manifest File Changes
 

With API version 100021 we are considering a couple changes to the manifest file processing:

1) File paths in the manifest file extend from the directory that the manifest file is in. Currently these file paths extend from "EsoUI/AddOns/<Manifest File Name>/" which is unintuitive and doesn't allow putting addons into a deeper file structure.
2) We will scan all sub-directories in the AddOns folder for manifest files. Currently we only scan the top level directories which also prevents putting addons into a deeper file structure.
3) Manifest files must have the same name as the directory they are in to be processed. This prevents ReadMe.txt files from being picked up as addons (along with other stray .txts), which becomes more important as the scan goes deeper. This seems to be the standard based on a subset of addons that I looked at, so hopefully most addons will already comply with this.

The main benefit of these changes is that it allows an addon to embed its libraries as addons instead of loading the files as part of the main addon manifest. Combined with the "# AddOnVersion:" directive, only the highest version of each library will be loaded which saves time that would be spent on loading the same library lua files many times and throwing out most of the results.

Let me know if you have any feedback on these changes.

So if you include 3 libs, will they then show up in someone's addon list for them to individually enable/disable? Inb4 commoners riot that we're installing bloatware!

Just to be sure:
The OnAddonLoaded event will still use <Manifest File Name> as addon name argument and SavedVariables files will still be called <Manifest File Name>.lua?

General feedback:
I think this is great, because it will automatically load newer libraries.
Currently an addon can load a bundled outdated library, if no newer version of the library was loaded via LibStub yet. This can cause errors if the outdated library isn't able to properly "unload", i.e. restore hooked API functions, when the newer addon version is loaded.
With the new changes the load order of the addons bundling the libraries doesn't matter anymore.

If I recall correctly, in the WOW addon community libs aren't bundled but have to be installed on their own. So users have all the libs in their addon list as well. However, I think you are totally right that there will be lots of question why the addon list suddenly increased by so many libX entries.

Even more fun will be the no longer maintained addons where the dev copied the txt of the libraries into the lib folder as well, but the lib's lua files are still loaded from the addon's txt. Then the checkbox in the addon list is totally useless because the lib will be loaded regardless.

I like the change to txt file processing, but I think there will only be a few libraries that want to go the full addon route. Users don't need to see "LibAsync", "LibTimeout", "LibLootSummary", "LibCustomMenu", etc. These are technical implementation libraries that will only serve to confuse users if they see them in their addons list. Perhaps if they were grouped together in a Libraries section of the addons list that is collapsed/hidden by default, it would reduce the confusion.

I'm in favor of that.

This change won't suddenly make libraries appear in the addon list out of nowhere. The author of the library will first have to update the lib so it properly works with this new feature. Existing libs will just continue to work like they have until now. I also suggest that old libraries don't just switch to the new way, and instead increase their "major" version so it won't affect existing addons.

LibAsync for example can stay how it is and doesn't have to be bundled as a standalone addon. That way it won't show up in the addon list. If an addon author doesn't read the description of a lib and includes it with a manifest file instead of how the lib author specified, it's something they should correct on their end. If it absolutely mustn't be included with a txt, then maybe do it like some other libs and just don't add one at all?

I would also wait and see if any user even notices this or is bothered at all. I don't believe it will be that much of a problem seeing as some addons already come with a lot of baggage anyways (e.g. Harvest Map, Master Merchant).

I do however agree that a library section and a way to see which path a library or addon was loaded from might be nice.

Shinni and sirinsidiator make very good points. Now you mentioned AddOnVersion and I wonder, how is it parsed and compared? Is it just a string? Does the game understand major, minor and revision numbers?

It's an unsigned integer.

I don't know what to think about it, it's both very good but it will be confusing and hard to implement without some global update..

So basically, now I have my libs loaded throught libstub, they don't have access to xml and savedvars (but for saved vars, I can cheat with zo_ingame..) and with this, my libs will be able to be full addons with their metafile and so on..

so why still embedding libs ?.. why not pushing them as full addons ?.. we're only doing the half of the way even if there is all we need to do the full thing.. Well, I'll still have to rethink about consequence and migration.

One thing is sure, I would really like to see the requests about addonmanager being done at same time. (API flag & System explorer)

I talked to our UI designer about this and we came up with adding a new checkbox to the addon window that auto manages dependencies and a new directive to mark an addon as a library. When you enable an addon it enables all addons marked as libraries that it depends on. And when you disable an addon, if libraries it was using became unused they are disabled. The addons marked as libraries would not be shown in the list in this mode. You could toggle off this auto mode and the libraries will be shown in the window and can be managed directly. Would something like this work?

That sounds pretty good to me. Is the "auto mode" enabled by default?

For addons being marked as libraries: is that automatic for nested addons (likely libraries) or is it something only possible via authors specifying it as such?

It would be default, yes.

I think it would be safer to do it manually since there aren't too many libraries and it prevents weird issues when people use non-standard organizations of their addons into folders.

Something that came into my mind:
How should we "register" our libraries?

Should we continue to embed LibStub?
Or is it wise to make LibStub build-in???

LibStub has changed exactly once to support minor version numbers. Which will be obsolete again.

Probably. I was just thinking about the many outdated addons whose libraries will now appear in the list simply because they haven't been updated. So if an old addon with LAM loads, then a new addon with LAM loads (let's assume they are the same version), will LAM show up in the addon (not the library) list because of the older one that was not specified as a library?

No. LAM has never been bundled with a txt until now. If I did change to the new system, it would be as LAM3.0

I didn't literally mean LAM, just any lib that a lot use. :P

It's the same for any lib that exists right now. I don't know of any that is bundled with an txt file included.