Thread Tools Display Modes
04/28/19, 02:18 PM   #1
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
Let's get rid of LibStub!

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:
Lua Code:
  1. local MAJOR, MINOR = "LibSomething", 3
  2. local lib = LibStub:NewLibrary(MAJOR, MINOR)
  3. if not lib then
  4.     return
  5.     -- already loaded and no upgrade necessary
  6. end
  7.  
  8. LibSomething = lib -- new way to access it without LibStub


In the manifest we also add the "AddOnVersion" and "IsLibrary" directive:
Code:
## 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.
Lua Code:
  1. local LS = LibStub("LibSomething")
should become
Lua Code:
  1. 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.

Lua Code:
  1. local lib = {}
  2. 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".

Last edited by sirinsidiator : 04/30/19 at 06:07 AM.
  Reply With Quote
04/28/19, 03:23 PM   #2
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
I will rewrite my libs to define a global variable. Some do already.
  Reply With Quote
04/28/19, 03:34 PM   #3
Drakanwulf
 
Drakanwulf's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2017
Posts: 50
@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.

Last edited by Drakanwulf : 04/28/19 at 03:38 PM.
  Reply With Quote
04/28/19, 03:44 PM   #4
Drakanwulf
 
Drakanwulf's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2017
Posts: 50
Originally Posted by votan View Post
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").
  Reply With Quote
04/28/19, 03:47 PM   #5
Rhyono
AddOn Author - Click to view addons
Join Date: Sep 2016
Posts: 659
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.
  Reply With Quote
04/28/19, 05:08 PM   #6
Kyoma
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 125
BURN IT DOWN! BURN IT ALL DOWN!!!
  Reply With Quote
04/29/19, 01:27 AM   #7
Scootworks
 
Scootworks's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2014
Posts: 312
Originally Posted by Kyoma View Post
BURN IT DOWN! BURN IT ALL DOWN!!!
BURN IT ALL DOWN! :-)
  Reply With Quote
04/29/19, 04:44 PM   #8
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
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.
  Reply With Quote
04/30/19, 12:29 AM   #9
Drakanwulf
 
Drakanwulf's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2017
Posts: 50
Originally Posted by Baertram View Post
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.
  Reply With Quote
04/30/19, 04:14 AM   #10
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,912
Oh, okay. Understood it's purpose wrong then. Thanks for the clarification.
  Reply With Quote
04/30/19, 05:49 AM   #11
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
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.
  Reply With Quote
04/30/19, 03:25 PM   #12
Drakanwulf
 
Drakanwulf's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2017
Posts: 50
@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.
  Reply With Quote
04/30/19, 04:29 PM   #13
Rhyono
AddOn Author - Click to view addons
Join Date: Sep 2016
Posts: 659
##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).
  Reply With Quote
04/30/19, 08:05 PM   #14
Drakanwulf
 
Drakanwulf's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2017
Posts: 50
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.

Lua Code:
  1. --[[-------------------------------------------------------------------------------------------------------------------
  2. Bootstrap code to either start or fail this add-on.
  3. ---------------------------------------------------------------------------------------------------------------------]]
  4. local addon = MapTables
  5. assert( not addon, "MapTables: This add-on is already loaded. Do NOT load add-ons multiple times!" )
  6.  
  7. addon = {}
  8. MapTables = addon
  9. assert( MapTables, "MapTables: The game failed to create a global control entry!" )
  10. --[[-------------------------------------------------------------------------------------------------------------------
  11. ... And add-on initialization code continues on from here ...
  12. ---------------------------------------------------------------------------------------------------------------------]]

What do you all think?

Last edited by Drakanwulf : 04/30/19 at 09:11 PM.
  Reply With Quote
05/01/19, 02:59 AM   #15
votan
 
votan's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2014
Posts: 577
I think Drakanwulf is afraid of addons including a lib the old way without making their addon optional depend on the stand-alone version.
  Reply With Quote
05/01/19, 03:07 AM   #16
Kyoma
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 125
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.
  Reply With Quote
05/01/19, 05:34 AM   #17
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
@Drakanwulf That looks pretty good. I use the following snippet for my own "new-style" libs:

Lua Code:
  1. local LIB_IDENTIFIER = "LibDebugLogger"
  2.  
  3. assert(not _G[LIB_IDENTIFIER], LIB_IDENTIFIER .. " is already loaded")
  4.  
  5. local lib = {}
  6. _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.
  Reply With Quote
05/01/19, 06:10 AM   #18
merlight
AddOn Author - Click to view addons
Join Date: Jul 2014
Posts: 671
Originally Posted by sirinsidiator View Post
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.
  Reply With Quote
05/01/19, 10:08 AM   #19
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,567
Originally Posted by merlight View Post
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.
  Reply With Quote
05/01/19, 12:07 PM   #20
merlight
AddOn Author - Click to view addons
Join Date: Jul 2014
Posts: 671
Originally Posted by sirinsidiator View Post
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.
  Reply With Quote

ESOUI » Developer Discussions » General Authoring Discussion » Let's get rid of LibStub!

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off