Wouldn't that put it in the same category as clcInfo itself, or kgPanels...
Well kinda, but its more of an in between as I see it. Those of the addons you mention that I know, work as hosts for plugins.
My module does absolutely nothing on its own, what it does is inject the class modules that use it with the plumbing needed to communicate with clcInfo, and common configuration pages to edit settings. In short it provides all the non class related stuff so that the author can focus on the class specific stuff.
So why don't I ask the author of clcInfo to merge this into clcInfo, which is where it belongs. Well I still have 2 month old tickets and private messages with no response so...
AceLocale and the CurseForge localization UI are completely independent.
Yeah I can see that now. And I can also see that making my own implementation would be just as easy.
Of course in order to share translations between multiple files, I would need to either expose it through LibStub or the addon table passed in at load or something similar.
So thanks for your answers, I appreciate you taking the time.
Far from being irrelevant, which libraries you're using is central to your question. Some libraries are intended to be used by other libraries; others are not.
You should not use AceLocale in a library. Just hardcode the translations. (I'd argue that nobody should ever use AceLocale for anything because it can be replaced with 5 lines of code, but that's another can of worms entirely.)
You should also not be using AceGUI in a library. If your addon is presenting a GUI to the user, it is not a library, or you are failing to properly separate the library's features from your addon's features.
Well I did clarify in my original post, that this isn't actually a library, it's a base module, an abstract class if you will.
It is however also not a standalone addon, as it does nothing on its own. It provides plumbing and the default UI elements for the very specific addon category for which it is a base. clcInfo class module plugins to be specific.
This is my second addon, and I am still learning the ropes. The use of AceLocale seemed like an obvious choice since it facilitates localization and it is easy for translators to provide translations through the curseforge interface.
Yeah I know I only need one pkgmeta, I just tried adding a second in the hope the packager would honor it during exernals resolution.
I believe my question has been answered, only the two options I listed are possible.
What I have done is write Xinhuan with my suggested improvement to the packager.
Ok, so I had a look at your library Myrrodin. And clearly you are doing option 2, leaving it to the consumer to ensure that all libraries required are loaded before yours.
Looking at AceComm-3.0 though it hard embeds ChatThrottleLib, so there we have my option 1.
So it seems my options are limited to those two, in which case I'l go for option 2.
Now if I could add behavior to the packager, I would add an option to the externals part, resolveExternals, which if set would cause the packager to resolve the externals of externals so to speak. That way consumers of a library would not have to know and satisfy the entire tree of dependencies; just the ones they use directly, the rest would be auto resolved.
I actually tried adding a second pgkmeta to the subfolder references by other addons in their externals. But no such luck.
@Phanx thanks but it seems you have misunderstood my question.
I am well aware that Ace is not the name of a library, however which library I am using is irrelevant to my question, but since you ask, I am using AceGUI and AceLocale.
I am not asking how to write toc or pkgmeta files, I am asking how a library that is using other libraries ensure that its external dependency requirements are met when another Addon developer embeds it, i.e. has it as an external in his pgkmeta.
Of the 2 listed options I wrote in my initial post, neither seems very smart, which is why I put it to the forum if there is a third option I am missing.
What you write in your bullet 2, suggests my option 2, which I agree is the lesser of two evils.
@Myrrodin thanks I will have a look at that, that is exactly what I was getting at.
I am currently creating a library, or rather a base module for other addons to build on. It is implemented as a library though.
Now this library uses a number of other libraries, like Ace and LibStub.
I would like it to conform to the default behavior of being able to install standalone (for no libs users) and be embeddable by addons that use it.
I have structured it in a way that toc, pkgmeta are at the root, and then the actual library is in a subfolder. Consumers of the library will then reference this subfolder to embed.
Now the problem is that when embedding, the libs folder (which should also go under the aforementioned subfolder) is not retrieved. This is fairly logical since it doesn't exist but is created by the packager as defined in the pkgmeta.
So what is the best practice to solve this?
1. I could hard embed the libraries used. This would break nolib conformity and I'd rather not do that. Plus its a pain to ensure they are the latest version.
2. I can make the libraries used required dependencies and make it the responsibility of the consumer of my library to ensure that the required libraries are loaded before mine. And then completely removed them from my addon pgkmeta and all.
Or is there a third option that will make it all work as intended, i.e. having the libraries retrieved dynamically also when embedding?
I am currently creating an addon that will serve as the basis for other addons, an abstract addon if you will.
So it will be used by multiple addons that will build on top of it, and there may be multiple such loading for a single toon.
Now my addon contains multiple files, which include a few widgets and locale files for each language among others.
So my concern is that I don't want all these files to be loaded again and again for each separate addon using it.
I see two options for solving this each with their own caveats and I would appreciate any input on which you would consider best practice or if a third better option exists.
1. Implement as a Library.
Using Libstub in the main code file which I would then load last and in it set a global that I can check the existence of at the start of locale files, widget lua files etc, and abort further loading if that global exists (versioned).
The main caveat I see here is that I can't see a way to do this check for widget xml files. Plus it is a bit cumbersome.
2. Implement as standalone addon
Main caveat here is that end users would have to download my addon themselves, in addition to the addons using it, and keep it up to date.
I apologize for the rather long post, but hope some will have thoughts on the matter.
0
Ok, that sucks. I'll try posting it anyway and see what happens. Thanks for pointing me in the right direction.
Well kinda, but its more of an in between as I see it. Those of the addons you mention that I know, work as hosts for plugins.
My module does absolutely nothing on its own, what it does is inject the class modules that use it with the plumbing needed to communicate with clcInfo, and common configuration pages to edit settings. In short it provides all the non class related stuff so that the author can focus on the class specific stuff.
So why don't I ask the author of clcInfo to merge this into clcInfo, which is where it belongs. Well I still have 2 month old tickets and private messages with no response so...
Yeah I can see that now. And I can also see that making my own implementation would be just as easy.
Of course in order to share translations between multiple files, I would need to either expose it through LibStub or the addon table passed in at load or something similar.
So thanks for your answers, I appreciate you taking the time.
0
Well I did clarify in my original post, that this isn't actually a library, it's a base module, an abstract class if you will.
It is however also not a standalone addon, as it does nothing on its own. It provides plumbing and the default UI elements for the very specific addon category for which it is a base. clcInfo class module plugins to be specific.
This is my second addon, and I am still learning the ropes. The use of AceLocale seemed like an obvious choice since it facilitates localization and it is easy for translators to provide translations through the curseforge interface.
0
Ok, I just saw him listed as author of a fair share of posts regarding the packager.
Could you provide me with the name of the proper person to contact regarding the packager?
0
I believe my question has been answered, only the two options I listed are possible.
What I have done is write Xinhuan with my suggested improvement to the packager.
0
Looking at AceComm-3.0 though it hard embeds ChatThrottleLib, so there we have my option 1.
So it seems my options are limited to those two, in which case I'l go for option 2.
Now if I could add behavior to the packager, I would add an option to the externals part, resolveExternals, which if set would cause the packager to resolve the externals of externals so to speak. That way consumers of a library would not have to know and satisfy the entire tree of dependencies; just the ones they use directly, the rest would be auto resolved.
I actually tried adding a second pgkmeta to the subfolder references by other addons in their externals. But no such luck.
0
I am well aware that Ace is not the name of a library, however which library I am using is irrelevant to my question, but since you ask, I am using AceGUI and AceLocale.
I am not asking how to write toc or pkgmeta files, I am asking how a library that is using other libraries ensure that its external dependency requirements are met when another Addon developer embeds it, i.e. has it as an external in his pgkmeta.
Of the 2 listed options I wrote in my initial post, neither seems very smart, which is why I put it to the forum if there is a third option I am missing.
What you write in your bullet 2, suggests my option 2, which I agree is the lesser of two evils.
@Myrrodin thanks I will have a look at that, that is exactly what I was getting at.
0
I am currently creating a library, or rather a base module for other addons to build on. It is implemented as a library though.
Now this library uses a number of other libraries, like Ace and LibStub.
I would like it to conform to the default behavior of being able to install standalone (for no libs users) and be embeddable by addons that use it.
I have structured it in a way that toc, pkgmeta are at the root, and then the actual library is in a subfolder. Consumers of the library will then reference this subfolder to embed.
Now the problem is that when embedding, the libs folder (which should also go under the aforementioned subfolder) is not retrieved. This is fairly logical since it doesn't exist but is created by the packager as defined in the pkgmeta.
So what is the best practice to solve this?
1. I could hard embed the libraries used. This would break nolib conformity and I'd rather not do that. Plus its a pain to ensure they are the latest version.
2. I can make the libraries used required dependencies and make it the responsibility of the consumer of my library to ensure that the required libraries are loaded before mine. And then completely removed them from my addon pgkmeta and all.
Or is there a third option that will make it all work as intended, i.e. having the libraries retrieved dynamically also when embedding?
0
0
I am currently creating an addon that will serve as the basis for other addons, an abstract addon if you will.
So it will be used by multiple addons that will build on top of it, and there may be multiple such loading for a single toon.
Now my addon contains multiple files, which include a few widgets and locale files for each language among others.
So my concern is that I don't want all these files to be loaded again and again for each separate addon using it.
I see two options for solving this each with their own caveats and I would appreciate any input on which you would consider best practice or if a third better option exists.
1. Implement as a Library.
Using Libstub in the main code file which I would then load last and in it set a global that I can check the existence of at the start of locale files, widget lua files etc, and abort further loading if that global exists (versioned).
The main caveat I see here is that I can't see a way to do this check for widget xml files. Plus it is a bit cumbersome.
2. Implement as standalone addon
Main caveat here is that end users would have to download my addon themselves, in addition to the addons using it, and keep it up to date.
I apologize for the rather long post, but hope some will have thoughts on the matter.