Let's get rid of LibStub!

[sirinsidiator]

I believe this can be done in 3 "easy" steps:

1) Update libraries to provide an alternative way of being accessed.
This step shouldn't introduce any major compatibility issues as we still keep everything as is and addons that have not been updated can use LibStub as a method to access the library as before. It's just to pave the way to phase out library access via LibStub in addons
All that should be necessary is to extend the code like this:

local MAJOR, MINOR = "LibSomething", 3
local lib = LibStub:NewLibrary(MAJOR, MINOR)
if not lib then
    return
    -- already loaded and no upgrade necessary
end
 
LibSomething = lib -- new way to access it without LibStub

In the manifest we also add the "AddOnVersion" and "IsLibrary" directive:

## AddOnVersion: 3
## IsLibrary: true

That's not strictly necessary until after LibStub has been removed from the lib, but it will ensure that only the newest standalone version is loaded (embedded versions will behave as before) and also move it to the new library section in the addon menu once Elsweyr is released.

2) Find all addons that use a library and change them (or request it) to access dependent libraries via the newly introduced global variable instead of LibStub, remove its files from the addon manifest (so it is no longer embedded) and change from OptionalDependsOn to DependsOn.

local LS = LibStub("LibSomething")

should become

lobal LS = LibSomething

3) Update libraries to no longer use LibStub. This will likely cause compatibility issues with any addons that have not been updated in step 2, but at some point we just need to pull the trigger, otherwise LibStub won't ever disappear completely.

local lib = {}
LibSomething = lib

Let me know what you think. Did I miss anything? Who's on board?
I will start with step 1 in LAMr28 and will introduce the new global variable "LibAddonMenu".

[votan]

I will rewrite my libs to define a global variable. Some do already.

[Drakanwulf]

@sirinsidiator, Excellent suggestion, sir. I think the sooner this is done, the more reliable our game environment will become and the better the Minion maintenance program will get at checking and verifying add-on packages before downloading them. I would be happy to help out in any way that I can be of assistance.

I have already done much of what you suggested as part of my pursuit of my "windmill" quest to load all my NA Live add-ons without having to turn the OOD checkbox ON. I have been successful by making the packaging and manifest files changes as you have suggested in this post.

Converting the add-ons to standalone and to current manifest settings was not difficult; mostly time consuming. The most difficult part was determining which of the add-ons needed their OOD library versions rather than the newer ESOUI versions because their add-on code that used the libraries had never been updated to use any of the updated library functions. I think these out-of-date, "private" libraries will prove to be an issue with add-ons that are no longer being maintained by anyone.

[Drakanwulf]

Originally Posted by votan I will rewrite my libs to define a global variable. Some do already.

Or you can take a look at the AddonStub standalone support add-on code and decide if its benefits are worth your adding its name to the DependsOn: directive in the manifest file (e.g. "## DependsOn: AddonStub").

[Rhyono]

The level of difficulty to make the switch is negligible. Most addons that are still heavily used are currently being maintained. If an addon is abandoned but still functioning and heavily used, I'm sure a few of us could patch it for such a minimal change.

[Kyoma]

BURN IT DOWN! BURN IT ALL DOWN!!!

[Scootworks]

Originally Posted by Kyoma BURN IT DOWN! BURN IT ALL DOWN!!!

BURN IT ALL DOWN! :-)

[Baertram]

Sounds good and should be easily doable. Only will take time

About "AddonStub": I did not really get what4 it can/should be used but I think removing 1 versioning lib to use another (kind of) one shouldn't be the solution. I'll go for ##AddOnVersion: and ##IsLibrary + global lib variable.

[Drakanwulf]

Originally Posted by Baertram Sounds good and should be easily doable. Only will take time About "AddonStub": I did not really get what4 it can/should be used but I think removing 1 versioning lib to use another (kind of) one shouldn't be the solution. I'll go for ##AddOnVersion: and ##IsLibrary + global lib variable.

AddonStub does not version anything. The game does that. What AddonStub does do is to check manifest content versus code content to insure that the AddOnVersion: directive and its number are both present and are both valid values. The rest of the code properly disposes of OOD duplicates and embedded duplicates or it creates a manifest table for all valid add-ons. And it updates existing add-ons whenever it detects a newer AddOnVersion: number.

[Baertram]

Oh, okay. Understood it's purpose wrong then. Thanks for the clarification.

[sirinsidiator]

I just took a look at this AddonStub and I'll be honest here. It is absolutely useless and pretty much the same as LibStub that we are trying to get rid of for that reason. Not sure why you would try to push this now?

Everything it is trying to do is handled by the game itself. There is no need to try avoiding loading duplicate addon names or check their addon version, since the game itself does exactly that. On the contrary, it is even slowing down the loading for no real reason, because it iterates over the whole addon list every time an addon is loaded, making it likely much slower than what the game itself does internally to handle multiple instances of the same addon in nested folders.

[Drakanwulf]

@sirinsidiator, your reasoning seems to be valid so I shall retire AddonStub from the ESOUI add-ons catalog provided someone who knows exactly how the game code works would volunteer to put a valid example into the ESOUI wiki that illustrates how to code a simple, consistent, start up logic with a trap in it to detect any mistakes and/or oversights in the game's add-on loading logic or execution.

Thanks again for taking the time to explain to me more of the things that I do not know about the game. It is appreciated.

[Rhyono]

##AddOnVersion should automatically solve all duplication issues. If the internal handler finds a second one with the same or lower version, it will just ignore them. Nothing special should need done within addons relying on another addon (except a DependsOn).

[Drakanwulf]

How is this for a standalone bootstrap example? Comments and critiques are expected and would be welcomed because I intend to update the MapTables support (i.e library) add-on calls to AddonStub with this snippet if I can get a consensus that this code will work and work efficiently.

--[[-------------------------------------------------------------------------------------------------------------------
Bootstrap code to either start or fail this add-on.
---------------------------------------------------------------------------------------------------------------------]]
local addon = MapTables
assert( not addon, "MapTables: This add-on is already loaded. Do NOT load add-ons multiple times!" )
 
addon = {}
MapTables = addon
assert( MapTables, "MapTables: The game failed to create a global control entry!" )
--[[-------------------------------------------------------------------------------------------------------------------
... And add-on initialization code continues on from here ...
---------------------------------------------------------------------------------------------------------------------]]

What do you all think?

[votan]

I think Drakanwulf is afraid of addons including a lib the old way without making their addon optional depend on the stand-alone version.

[Kyoma]

If your library never used LibStub then there's no need to worry about addons not properly using your library. Well, unless they decide to modify the library packaged with their addon.

[sirinsidiator]

@Drakanwulf That looks pretty good. I use the following snippet for my own "new-style" libs:

local LIB_IDENTIFIER = "LibDebugLogger"
 
assert(not _G[LIB_IDENTIFIER], LIB_IDENTIFIER .. " is already loaded")
 
local lib = {}
_G[LIB_IDENTIFIER] = lib

You can probably drop the second assert, since that should never ever be possible to happen, and if it does happen, you have other problems.

@Kyoma the assert is mostly in case other developers decide to start making a new addon with that name, so they get a warning right away.

[merlight]

Originally Posted by sirinsidiator I believe this can be done in 3 "easy" steps:

But why?

I fail to see any real benefit in dropping LibStub, other than getting rid of a bunch of copies of one tiny source file. LibStub sets up a common namespace for libraries. All you're going to achieve is spill that namespace into the global one. To quote a classic:

Namespaces are one honking great idea -- let's do more of those!

At the same time you're winding up to break unmaintained addons just for the sake of breaking them -- when libraries they use get an upgrade that will not register with LibStub anymore.

[sirinsidiator]

Originally Posted by merlight But why? I fail to see any real benefit in dropping LibStub, other than getting rid of a bunch of copies of one tiny source file. LibStub sets up a common namespace for libraries. All you're going to achieve is spill that namespace into the global one. To quote a classic: Namespaces are one honking great idea -- let's do more of those! At the same time you're winding up to break unmaintained addons just for the sake of breaking them -- when libraries they use get an upgrade that will not register with LibStub anymore.

The main reason is to remove a troublesome piece of code that has caused countless problems for authors due to the way it handles library versioning. The game itself can now handle the versioning better than LibStub ever could. I'm also not worried about the few extra namespaces in an environment where we have almost 50k global variables. What even is the benefit of having all libraries in one namespace, or is it just for the sake of it?

Unmaintained addons will continue to load their own embedded LibStub and version of any libs as before, so I don't see how they would be affected by library updates that no longer use LibStub.

[merlight]

Originally Posted by sirinsidiator The main reason is to remove a troublesome piece of code that has caused countless problems for authors due to the way it handles library versioning. The game itself can now handle the versioning better than LibStub ever could. I'm also not worried about the few extra namespaces in an environment where we have almost 50k global variables. What even is the benefit of having all libraries in one namespace, or is it just for the sake of it? Unmaintained addons will continue to load their own embedded LibStub and version of any libs as before, so I don't see how they would be affected by library updates that no longer use LibStub.

You're right. I sometimes forget that my way of installing addons without embedded libraries is not how everyone else does it.