Addon dependencies
 

Since more and more authors are now finally switching to move libraries out of their addons and have users install them as separate addons, it would be great if we could have some way to specify these dependencies on the addon page and have minion install them together with the addon (I wouldn't mind creating a pull request, but minion is still not on github ;) )
A panel for authors to show which addons depend on their library would also be nice.

When I first heard of this practice, I had a similar idea. Now I think it would be a terrible idea.

As I pointed out in a different thread towards one of these authors, since the libraries are rarely updated and their stand alone versions are almost always Out of Date, it's a VERY BAD idea to force people to use stand-alone libraries.

Enabling Minion to download out of date standalone libraries to support a non-compliant addon would simply encourage a very bad programming practice. Instead, we should be strongly objecting to anyone who is releasing addons without their needed libraries and doing everything we can to discourage that practice.

IMHO.

Just let's Minion would check if required Libs are already installed and suggest to install it if not.

The problem is, libraries for ESO need to be updated rather frequently due to changes made by ZOS. And what standalone libraries are we talking about that are 'almost always Out of Date'?

Um... LibStub? LibAddonMenu? LibFilters? You know... the ones nearly every addon uses? LibStub alone causes other libraries to not load as well because it's standalone version is woefully out of date.

And how frequently are we talking about for the other libraries, really? How many of them change, and how often? There really shouldn't be a need to update most of them all that often.

I can tell you two things. The benefits of making libraries into separate addons far outweigh small issues like this and some libraries simply don't need updates on every new game version (like LibStub or LibAddonMenu).

If we don't move forward, we will never see what has to be changed in order to make it "right". You bringing up this issue is just one more argument to just do it. ;)

If you still refuse to enable the checkbox "use out of date" addons:
You are totally able to update the api version in the standalone libs txt files after a major patch.
This will maybe force you, if you want the libs not to appear "out of date" for you, to change the txt files of 3-5 libraries.
As the standalone libs got their own folder you'll find them quickly, and its easy to change the files then at teh entry ##APIVersion.

Think about this:
If you would need to change them inside the addon folders as well, where you would need to find the most up2date version first and then check dependencies and understand how the game loads the libraries and addons, in which order etc,...
It wouln'd be possible for you to find the correct library loaded! Or you'd need to increase the library version locally so you force the game to load this folder.

What are the benefits of not including libraries in the client addons, aside from a smaller install package?

The same as using libs and not including a typical functions inside a main code of your addon :banana:

Standardization.

Standardization is provided by using libraries.
Including the libraries with your addon ensures that you never have to try to run with a library whose version is older than YOU require.
LibStub ensures that you run with the best (well, newest) version that is available.

So, I do not understand why I would not want to package libraries I rely on with my addons?

Due to the nature of (many) libraries containing code that somewhat "hacks" the ZOS code it may require updating after alot of API updates. As such, all addons containing the library will need to be updated by each of their author just to include a "fixed" version of the library. Even when the actual addon code didn't need any changes. While this may be manageable for some, it can quickly become a maintainance nightmare.

Bundled libraries need updates every single small patch or change which ZOs does.
This will take so much time we could simply invest intot the addons. And even if you only got 1-5 addons to maintain there are ppl who got about 30+. Think about this time "nightmare" (liky Kyoma wrote about).
You don't must follow my rules or decision! I never said that. But I decided that I won't invest this time into updating libraries anymore if the base design of libraries is another one and it got so many advantanges. Way more then disadvantages (and please don't count peoples time to update libraries and instal lthem as standalone as an disadvantage. It only has to be done once and afterwards Minion will handle it. And if you decided to install/update them manually it's the same like updating addons.).


Putting a piece of code "redundantly" in each addon just to have to remove or update those again after a while because it is non-functional again, makes no sense. Libraries are not designed to be put in each addon's folder construct. They should be put once into the game and used by all addons then.
There might be some which behave differently (LibGroupSocket e.g.) if you ship them bundled or as standalone.
But about 90% are designed to be used 1 time, standardized.

You can simply keep it divided from the addon, put it in an extra folder where you can easily find and maintain (the txt file e.g. if you want the API version raised) it, debug error messages etc.
-> Imagine you want to update the txt file of a library but do not know which of the 25 addons subfolders was the one which loaded the library for you now? You'd need to check each txt file to see the Version and compare which is the newest version. Then you'd need to check dependencies in the txt files between all of those addons or you might not see what is the load order and which library was loaded when. A nightmare to debug and to check imo.

Bundled libraries point to an addon where they got loaded if an error message happens. This will misslead you to the addon as the error raiser (maybe).

Plus you have more free space on your harddrive and the loading time of addons increases as well.

I see both sides and I agree that a way for authors to define dependencies would be a great feature for the site. Maybe even something added to the addon.txt that Minion could read with the dependency name and addon id.

This still leaves things a little messy for those that download AddOns by hand. I guess we could have the site auto include any dependency in the zip when downloading from the site?

The txt files already got the entries for the dependencies:
I do not know if Minion would be able to read those, split it at the space character and build a lookup addon/library table which will be checked against www.esoui.com database for addonname = addonId then?

Having the website download marked dependent addon/libraries automatically would be great.
But I guess this would need to be all in one zip file which simply needs to be extracted to the Elder Scrolls Online/live/AddOns folder then, or there will be several .zip files and the user might not know which one to extract? Not sure how this could work at best.

Matching the addons just by the name in the manifest may end up with an incorrect file as we already have seen with some language patches etc in minion. On the other hand, specifying the addon id could be too restrictive in case some dependency gets abandoned and reuploaded by someone else under a new id. It may be necessary to allow addon authors to specify how the ids are related to each other (language patch, continued version, extension, beta) and also give authors control so they can "block" an id from being considered in case the continued version gets abandoned and the original returns.

Zipping up all dependencies in one archive would be very convenient, but depending on how you do it, it could also produce some broken results. Maybe just put the separate zip files into one big archive instead of their individual content and let the user figure out where to put what, because an author who forgot to structure it correctly or already uses the same folder as one of the other dependencies could end up breaking the downloaded version. If you change the download button to work that way, it might also be nice to have a smaller button that downloads just the addon itself without the dependencies.

esoui.com could create a "inclusive" zip file with the declared dependencies in their own folder. Probably the easisest way imho.

Not manually done, you declare dependency and there's an optional download that includes those folders in a big zip.

I think better would probably be an esoui-specific manifest-type file where authors can specify the library links or ids or something that their addon depends on so that esoui/minion can parse to see what else may need downloading. Authors that don't participate in the new paradigm yet, don't include this file.

Does anyone have any information about whether this feature is being worked on? I did not find any posts here or notes on the Minion website about active development of new features (e.g. Minion 4).

Yep, but just slowly. Right now I'm working on getting some needed information into the web api for Minion to support the feature. Then sirinsidiator has stepped up to help on the Minion java end of things. I really can't give an eta but its being worked on still.

Nice to hear! Thank you for your work. I'm looking forward to the new feature :D

Yo! Any new information about this feature? :)

It's still in being worked on. Just takes a bit longer due to a lack of time.

Top-notch <3

I am having the same problem. My Master Merchant will not work. Can not find out why. It say dependency. What is that?
:mad:

Dependency = other source code needed like in libraries.
Just click the Master Merchant entry in the addon manager and expand it and there you'll find the "deoendencies" listed you need to install (e.g. LibStub, LibAddonMenu-2.0, ...)
Or install "Votans Addon List" and you'll see the dependencies in the red (i) icon on the right side in the row of the addon. If you already own the dependencies it will automatically enable it for you.

Related query - since Elsweyr released, many people are now saying "you install Libraries separately". Is that technically accurate (and therefore advisable), or is it a misinterpretation on what ZOS have actually done?

In other words, should I still be including Libraries within my add-on in a Libs folder with OptionalDependsOn in my manifest, or should I be using DependsOn in my manifest, without a Libs folder, and stating the Libraries should be standalone and installed separately as prerequisites?

As an author, you switch away from the LibStub embedded way of adding source files to your own manifest. Instead you should use DependsOn for libraries that have to be loaded and OptionalDependsOn for libs that may be loaded. In any case you will have to check the library if it has been updated to support this.

Once you have done that, you can decide for yourself if you still want to bundle the libs with your addon, or have the users install them separately. Having them installed separately will cause less problems in the future (in case another addon is depending on a newer version of the lib, but doesn't have it bundled) and you won't have to update the bundled libs yourself any more. It also has slightly better performance (less folders to scan for the game), but that's likely only in the ms-range.

OK cool thanks. So just to check that I understand correctly - in terms of LAM, which is obviously the primary example that I know has already been updated:

The library in question needs to have its own manifest txt file, which must include:

The individual add-on's manifest txt file needs to change from:
to:

And the add-on code itself needs to change from:

to:

Then the library could or could not be bundled in the add-on directory, and the game will load it from the add-on or from standalone depending on which is the most recent version.

Is that everything in summary? Thanks!

That's mostly correct.
The IsLibrary flag is actually just so the game knows that it has to show it in the library list on the bottom of the addon menu. The more important thing is to specify an AddOnVersion. Otherwise the game cannot know which version is the newest one in case there are several copies present.
And the global variable is just "LibAddonMenu2" and not "LibAddonMenu-2.0", since Lua would interpret that as "nil - 2" and throw an error. ;)