Hey everyone, so I finally pushed LDB to an ace repo (you can thank the point system for that). I'm still going to be a picky bitch about .pkgmeta though...
edit
Apparently Ace's packager is not smart enough to handle libraries that don't have a standalone version (odd, LibStub and CallbackHandler are supposed to always be hard-embedded). This means that you should not use an embed entry in your .pkgmeta for LDB.
You can vote up this ticket to help encourage a fix.
Make sure you HARD-embed LDB, Libstub and CBH into your addon, don't use an embed entry in your .pkgmeta. You should have already been doing this anyway, if you weren't, for shame!
To make the relationship happen you simply need to add a "tools-used" entry to your .pkgmeta if you have one. If you don't have a .pkgmeta, you can edit the default relationships on your project page on wowace. Use "libdatabroker-1-1" for these entries. After that, you'll need to make new tags or edit the relationships on the newest beta and release files on wowace.
if you don't use .pkgmeta, you can use this script to update en-masse:
You'll need ruby of course, and your wowace API token. That script looks for git repos, if you use svn (booo) then you'll have to tweak the script accordingly.
Thank you to everyone that sets up relationships on your addons... points now pay for my wow subscription, which in turn encourages me to write more code (like you could stop me anyway...)
hmm only one problem if i pull from wowace then i have to turn off the -nolib creation otherwise LDB will not be included in -nolib version and will be downloaded separately but since it doesn't come with a toc file it will not run and will error out
Are you sure it doesn't simply hard-embed LDB as it did when you were pulling from github? If it doesn't, I would consider that a bug with the packager. No ToC should be treated the same as pulling off-site.
Are you sure it doesn't simply hard-embed LDB as it did when you were pulling from github? If it doesn't, I would consider that a bug with the packager. No ToC should be treated the same as pulling off-site.
You don't need to release a new beta/release, just edit the latest file(s) on the web page. I noted that in the OP and the script I posted will make those changes for you.
Im only going to post about this once. The means your using to get your points is abusively obscene.
Because of this im removing LDB support from my addons, the code to use LDB if precent will remain and become entirely optional, however im removing the lib entirely from my project.
I encourage others to do the same, we (Authors) shouldn't have to jump though the gauntlet and the bowles of the wowace packager system to satisfy your distaste for setting up a lib properly to be used here.
***
Edit: However I fully support changing the way libs are handled at the site level where if the lib dosn't have a ToC File it's treated differently. But the "Special Snowflake" handling is what i have the problem with.
I'm not forcing anyone to do this, I'm only asking. I've provided (and updated many times) instructions and a script. I'm not the one that designed the point system the way it was designed, and from day one I've told people to NOT use .pkgmeta with LDB.
LibStub and CBH are not supposed to exist as standalone libraries. They still can be embedded using externals or the like, which is not hard-embedding strictly speaking.
LS and CBH are a double-special case because they need to be embedded for every lib that uses them, but only once per addon to avoid lots of undue loading. So if every addon that uses them has a standalone, that standalone should include them, and they don't need to be in the addon. If a lib doesn't have a standalone, and the addon can't OptDep a lib that does, then they need to be embedded in the addon. LS is fairly easy to come by, but CBH isn't usually.
As I told orion... I'm stubborn and this is the design I've chosen and lived with for well over a year (two?) now. I'm not interested in what I would consider a de-evolution of my code just because ace's system forced it (which it doesn't really, just use "tools-used" and nothing else has to change from how people were doing it before).
Personally, I partially agree with Orion (minus the "abusively obscene" part and removing support) and will keep the LDB embed straight to the .toc. There is really very little reason to try and invert "workarounds" for the packager, so that both lib and nolib packages will work as expected, not to mention cumbersome. I also don't see the problem with LS and CBH getting embedded via the .pkgmeta. It's been like that since hrm ages ?
If somebody is only using LibStub, CBH, and LDB in their addon then they should just disable nolibs instead of hard-embedding. LibStub and CBH should never be hard-embedded on WoWAce/CurseForge repos (but there are still a lot of old libraries that do and should be fixed if they weren't mostly dead).
I think you deserve credit for your work Tek, but I think you need to follow the rules and work within the system just like the rest of us if you want *reward points*.
Both LibStub and CBH have standalones. They are no longer "special snowflakes", and can be embedded and optdeped just like any other library. I think LDB is the only library that exists that needs hard embedding.
I think you deserve credit for your work Tek, but I think you need to follow the rules and work within the system just like the rest of us if you want *reward points*.
Both LibStub and CBH have standalones. They are no longer "special snowflakes", and can be embedded and optdeped just like any other library. I think LDB is the only library that exists that needs hard embedding.
What rules? Because the system is designed around one use doesn't make that use a rule you know. Ace has always been about encouraging good code, not about enforcing specific designs.
Because of this im removing LDB support from my addons, the code to use LDB if precent will remain and become entirely optional, however im removing the lib entirely from my project.
How petty and obnoxious. Yes, making life difficult for the thousands upon thousands of addon users who don't know that libraries even exist, let alone how to manage a standalone library setup (which everyone around here seems to think is horrible and useless and evil nowadays anyway), just because you disagree with one library author's view on how his library should be distributed is really a great way to prove your point. :rolleyes:
Also, unless I misunderstand how the point system works, how is he "abusing" anything? Are different amounts of points given depending on whether a library is listed as an "external/embed" or a "tool used"?
"tools-used" was added because Ackis was including data-tools as an embedded library in ARL so that data-tools would get reward points since he heavily used it. It is the exact same thing as an embedded library as far as points go but it does not cause the nolib mode of the Curse Client to try and install a standalone, which is the problem Ackis caused.
Hard embedding should never be done because external code not under the control of the addon author should not be in the addons repo. This is even worse for LDB because LDB does not have any copyright notice anywhere so every addon that is hard embedding LDB without adding an exception for it to its own license information is technically violating copyright. I'm sure Tekkub doesn't want LDB under GPL but a GPL addon hard embedding it with an exception being listed is technically illegally declaring that it is under the GPL. The same could be said for addons that reference it as an external too but in that case the repo does show evidence that the file comes from somewhere else.
The "license-output: LICENSE.txt" .pkgmeta feature of the repos should probably be changed to give the license of the addon and all embedded libraries automatically when used, but that still wouldn't even help in a hard-embedded situation.
If Tekkub does not want there to be a standalone version of LDB then he should tell authors to disable nolib zips for their addons using "enable-nolib-creation: no" not by encouraging hard embedding of the library.
I support the idea of allowing libraries to be specified as not having standalone versions and always being included in nolib zips because of LibStub and CallbackHandler, but since I have been fighting for that since WoWAce moved to the CurseForge system and there has been no sign of anybody with the power to make that change supporting the idea so I see it as a lost cause.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
edit
Apparently Ace's packager is not smart enough to handle libraries that don't have a standalone version (odd, LibStub and CallbackHandler are supposed to always be hard-embedded). This means that you should not use an embed entry in your .pkgmeta for LDB.
You can vote up this ticket to help encourage a fix.
Make sure you HARD-embed LDB, Libstub and CBH into your addon, don't use an embed entry in your .pkgmeta. You should have already been doing this anyway, if you weren't, for shame!
To make the relationship happen you simply need to add a "tools-used" entry to your .pkgmeta if you have one. If you don't have a .pkgmeta, you can edit the default relationships on your project page on wowace. Use "libdatabroker-1-1" for these entries. After that, you'll need to make new tags or edit the relationships on the newest beta and release files on wowace.
if you don't use .pkgmeta, you can use this script to update en-masse:
<script src="http://gist.github.com/153863.js"></script>
You'll need ruby of course, and your wowace API token. That script looks for git repos, if you use svn (booo) then you'll have to tweak the script accordingly.
Thank you to everyone that sets up relationships on your addons... points now pay for my wow subscription, which in turn encourages me to write more code (like you could stop me anyway...)
File a ticket ? :)
You don't need to release a new beta/release, just edit the latest file(s) on the web page. I noted that in the OP and the script I posted will make those changes for you.
Updated the OP with instructions on using tools-used in .pkgmeta, since repos with .pkgmeta files can't edit default relationships.
Because of this im removing LDB support from my addons, the code to use LDB if precent will remain and become entirely optional, however im removing the lib entirely from my project.
I encourage others to do the same, we (Authors) shouldn't have to jump though the gauntlet and the bowles of the wowace packager system to satisfy your distaste for setting up a lib properly to be used here.
***
Edit: However I fully support changing the way libs are handled at the site level where if the lib dosn't have a ToC File it's treated differently. But the "Special Snowflake" handling is what i have the problem with.
Both LibStub and CBH have standalones. They are no longer "special snowflakes", and can be embedded and optdeped just like any other library. I think LDB is the only library that exists that needs hard embedding.
Seconded.
How petty and obnoxious. Yes, making life difficult for the thousands upon thousands of addon users who don't know that libraries even exist, let alone how to manage a standalone library setup (which everyone around here seems to think is horrible and useless and evil nowadays anyway), just because you disagree with one library author's view on how his library should be distributed is really a great way to prove your point. :rolleyes:
Also, unless I misunderstand how the point system works, how is he "abusing" anything? Are different amounts of points given depending on whether a library is listed as an "external/embed" or a "tool used"?
Hard embedding should never be done because external code not under the control of the addon author should not be in the addons repo. This is even worse for LDB because LDB does not have any copyright notice anywhere so every addon that is hard embedding LDB without adding an exception for it to its own license information is technically violating copyright. I'm sure Tekkub doesn't want LDB under GPL but a GPL addon hard embedding it with an exception being listed is technically illegally declaring that it is under the GPL. The same could be said for addons that reference it as an external too but in that case the repo does show evidence that the file comes from somewhere else.
The "license-output: LICENSE.txt" .pkgmeta feature of the repos should probably be changed to give the license of the addon and all embedded libraries automatically when used, but that still wouldn't even help in a hard-embedded situation.
If Tekkub does not want there to be a standalone version of LDB then he should tell authors to disable nolib zips for their addons using "enable-nolib-creation: no" not by encouraging hard embedding of the library.
I support the idea of allowing libraries to be specified as not having standalone versions and always being included in nolib zips because of LibStub and CallbackHandler, but since I have been fighting for that since WoWAce moved to the CurseForge system and there has been no sign of anybody with the power to make that change supporting the idea so I see it as a lost cause.