ESOUI

ESOUI (https://www.esoui.com/forums/index.php)
-   General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)
-   -   Let's get rid of LibStub! (https://www.esoui.com/forums/showthread.php?t=8492)

sirinsidiator 04/28/19 02:18 PM

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".

votan 04/28/19 03:23 PM

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

Drakanwulf 04/28/19 03:34 PM

@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 04/28/19 03:44 PM

Quote:

Originally Posted by votan (Post 37910)
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 04/28/19 03:47 PM

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 04/28/19 05:08 PM

BURN IT DOWN! BURN IT ALL DOWN!!! :banana:

Scootworks 04/29/19 01:27 AM

Quote:

Originally Posted by Kyoma (Post 37915)
BURN IT DOWN! BURN IT ALL DOWN!!! :banana:

BURN IT ALL DOWN! :-)

Baertram 04/29/19 04:44 PM

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

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 04/30/19 12:29 AM

Quote:

Originally Posted by Baertram (Post 37938)
Sounds good and should be easily doable. Only will take time :D

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 04/30/19 04:14 AM

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

sirinsidiator 04/30/19 05:49 AM

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. :rolleyes:

Drakanwulf 04/30/19 03:25 PM

@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 04/30/19 04:29 PM

##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 04/30/19 08:05 PM

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?

votan 05/01/19 02:59 AM

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 05/01/19 03:07 AM

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. :p

sirinsidiator 05/01/19 05:34 AM

@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. :D

merlight 05/01/19 06:10 AM

Quote:

Originally Posted by sirinsidiator (Post 37909)
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 05/01/19 10:08 AM

Quote:

Originally Posted by merlight (Post 37969)
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 05/01/19 12:07 PM

Quote:

Originally Posted by sirinsidiator (Post 37978)
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.


All times are GMT -6. The time now is 12:58 PM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI