There has been talk about a new Curseforge packager in development, and some bugs that will be addressed and fixed. I thought to create a suggestion thread, primarily for non-bugs, but if someone has some that are not talked about already, feel free to add them here.
In the pkgmeta, I would like to see the move-folders ability to be further recursive to the Interface folder, allowing authors to create or add to a Fonts, Sounds, etc setup. This would make creating full UI replacements much easier with the Curse Client. Right now, end users must be informed and move such folders themselves, whereas it is the job of the packager and the Curse Client to automate such activities.
There ought to be a flag or ability for authors to expressly remove libraries that are no longer in use by their AddOn in a no-lib-strip environment. This also could be in the pkgmeta, and be "smart" the way the Curse Client is. If an author writes AddOnA and it currently uses LibSharedMedia, the CC will install LSM no-lib-strip. If AddOnB uses LSM and you try to remove it, the CC will notify the user. So far so good. However, if the user only has AddOnA and never installs AddOnB, and then the author of AddOnA decides to no longer use LSM, the CC updates AddOnA but leaves LSM installed for no reason. In such a case either the Curse Client need to get smarter, or a new flag in the pkgmeta (call it remove-folder or delete-folder) needs to exist.
Number 2 above is trickier, as in an ideal situation, there is no need to add a new pkgmeta tag, but the Curse Client needs to get smarter about updating and removing unnecessary leftovers. I do realize that if you delete an AddOn that uses a library, the Curse Client will delete the library if no other AddOn uses it. I am talking about upgrading an AddOn, not deleting one. During the upgrade process the system is not smart.
Hmm, I just had a further thought about number 1: some UI replacements come packaged with settings pre-configured. Having move-folders be able to move folders to the WTF and Interface folders, along with the AddOns folder, would ease many headaches. The system would have to have enough brains to overwrite existing data, but to not remove all data. You would not want to blitz your SexyMap settings if the incoming UI package settings don't include SexyMap, but if the new settings overwrite your existing Bartender4, that would be fine.
#2 shouldn't really be an issue since most libraries are LOD. If no addon is actually using them, they'll never get loaded anyway.
Something that would be useful would be a way to embed libraries that don't have standalone versions on Curse (or at all). Currently the only ways to handle that situation are (a) turn off -nolib packages for your addon or (b) hard-embed the library file in your repository. Neither are ideal. LibDataBroker is a well-known example of an addon that doesn't have a standalone version, but the same issue makes it tricky to use libraries that aren't hosted on Curse, as listing them as externals causes them to be left out of -nolib packages, resulting in users simply not getting the libraries the addon needs, or having to go to google to find them themselves on other sites. This could be fixed with the addition of a new .pkgmeta field for listing externals that should still be included in -nolib zips, or by automatically assuming that any externals coming from non-Curse repositories should still be included in -nolib zips.
The behavior I'd always seen for offsite repositories was that nolib ignored their omission. Using your LibDataBroker example, I have that pulling down from GitHub, and it's included even in the -nolib files. The only tricky part is placing its inclusion OUTSIDE of the strip sentry.
In the pkgmeta, I would like to see the move-folders ability to be further recursive to the Interface folder, allowing authors to create or add to a Fonts, Sounds, etc setup. This would make creating full UI replacements much easier with the Curse Client. Right now, end users must be informed and move such folders themselves, whereas it is the job of the packager and the Curse Client to automate such activities.
This is not going to work, at least not in the "packager". It still has to generate ZIP files which need to be the same general addon layout as always before, which means you can just unpack them into the Interface/AddOns folder and be done with it. The packager cannot move anything out of this structure.
That said, the Curse Client could still somehow offer this with some other magic, however not something the packager does.
PS:
Replacing WoW assets is a "questionable" practice at best, imho.
Hmm, I just had a further thought about number 1: some UI replacements come packaged with settings pre-configured. Having move-folders be able to move folders to the WTF and Interface folders, along with the AddOns folder, would ease many headaches. The system would have to have enough brains to overwrite existing data, but to not remove all data. You would not want to blitz your SexyMap settings if the incoming UI package settings don't include SexyMap, but if the new settings overwrite your existing Bartender4, that would be fine.
If you write a "UI replacement" and can't shove your initial settings into a normal addon, you shouldn't be writing this stuff in the first place. Curse Client messing with the SVs directly is going to hurt someone!
All good points, some of which I hadn't thought all the way through. To Phanx's point about most libs being LoD, while true, I can think when people stopped using LibBabble-Zones in favour of GetMapInfo(), when you updated an affected AddOn, it left LB-Z installed where it should have removed the lib. Users had to do the clean up themselves, and the vast majority of them didn't know how or why.
Another example might be my own SmartRes2. When I switched from LibResComm to LibResInfo, when the Curse Client updated SR2, it left LRC installed. LRC is not LoD.
Replacing WoW assets is a "questionable" practice at best, imho.
Nothing questionable about replacing files to mute obnoxious and unnecessary sounds -- like that @#$%ing Millhouse Manastorm toy that shouts stupid things in that horrible horrible voice -- and there's no other way to do it.
The behavior I'd always seen for offsite repositories was that nolib ignored their omission. Using your LibDataBroker example, I have that pulling down from GitHub, and it's included even in the -nolib files. The only tricky part is placing its inclusion OUTSIDE of the strip sentry.
Hmm, you're right, but there's still a problem with library dependencies -- if LDB is the only library the addon uses, for example, you also need LibStub and CallbackHandler, but since those are hosted on Curse, they are not included in the -nolib package, and the addon will fail to load.
I believe that's why the general recommendation has always been to hard-embed those two - they're rarely updated...perhaps the last time was 2009? Not that I typically follow that recommendation, though. Good point, though.
The .pkgmeta format could always be extended so that an "externals" listing could have an "embed" key that defaulted to a boolean value of "no", but could be set to "yes" to include that external checkout in a -nolib package, e.g.,
Then you wouldn't need to hard-embed anything in your addon. The .pkgmeta instructs the packager to always include the external checkout in the package, -nolib or not.
But Torhal, that doesn't solve the problem, which is that the packager doesn't include the library in the package in the first place.
At present we can work around that problem by (as you pointed out earlier in this thread or in the other one) using non-Curse external URLs or by hard-embedding, but hard-embedding is far from ideal, and using non-Curse URLs only partly solves the problem unless you're willing to set up non-Curse mirrors for libraries, which seems like an obviously bad practice. It would just be better to have an official solution that's actually a solution rather than a clumsy workaround.
Torhal is working on Archy; however, as I suspected, the latest updates do not remove LibBabble-Artifacts-3.0 when updating via the Curse Client. The Curse Client should, IMHO, be smart enough to know when to remove a former dependency when it is no longer required. After all, it no longer is referenced in the pkgmeta or ToC files.
Either that, or my previous suggestion, which could be a "check all dependencies" flag in the pkgmeta. If not match is found, delete the dependencies.
This will happen again to Archy when Torhal has finished the code to invalidate LibBabble-DigSites-3.0.
I have seen this behaviour in the Curse Client before, as AddOns no longer require dependencies. It happened with Ace-Ace2-Ace3 (yeah, different updaters, point still valid for current Curse Client) and several other cases.
On a side note, given that when Blizzard patches the game and significantly alters previous APIs, historically library files get updated before the AddOns that depend on them. Therefore, I suggest to alleviate (not eliminate) user frustration, the Curse Client should default to no-lib-strip installations, and have embedded as the option. Reverse of the status quo.
This is only a problem when you use disembedded libraries, which is not something thats really recommended for the general user, so go deal with it yourself. :)
Libraries like this should be Load-On-Demand anyway, so they wouldn't load in the game anymore when they are no longer used.
I suggest to alleviate (not eliminate) user frustration, the Curse Client should default to no-lib-strip installations, and have embedded as the option. Reverse of the status quo.
Not a good idea. Libraries are embeddable to remove them from the user's concern, which is good because it reduces the amount of technical understanding the user needs to install and use libraries -- even if the Curse Client installs libraries for the user, they still have to see them and think about them when using the in-game addon manager to enable or disable addons.
For example, the average Bartender4 user doesn't know or care what libraries are. If they suddenly start seeing 9 extra folders -- Ace3, CallbackHandler, LibActionButton, LibButtonGlow, LibDBIcon, LibDualSpec, LibKeyBound, LibStub and LibWindow -- in their addon list, they're going to be really confused; they might disable or even delete those libraries (because they don't know what they're for) and then be frustrated when Bartender4 doesn't work; and they're likely to (incorrectly) start viewing Bartender4 as "bloated" because it uses so many libraries, and the average user doesn't understand how libraries work any more than they understand the real effects of static memory usage -- and frankly, they shouldn't have to understand those things, or have it shoved in their faces that stuff is going on that they don't understand. The technical stuff should just be hidden away where they can't see it and don't have to think about it.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator- In the pkgmeta, I would like to see the move-folders ability to be further recursive to the Interface folder, allowing authors to create or add to a Fonts, Sounds, etc setup. This would make creating full UI replacements much easier with the Curse Client. Right now, end users must be informed and move such folders themselves, whereas it is the job of the packager and the Curse Client to automate such activities.
- There ought to be a flag or ability for authors to expressly remove libraries that are no longer in use by their AddOn in a no-lib-strip environment. This also could be in the pkgmeta, and be "smart" the way the Curse Client is. If an author writes AddOnA and it currently uses LibSharedMedia, the CC will install LSM no-lib-strip. If AddOnB uses LSM and you try to remove it, the CC will notify the user. So far so good. However, if the user only has AddOnA and never installs AddOnB, and then the author of AddOnA decides to no longer use LSM, the CC updates AddOnA but leaves LSM installed for no reason. In such a case either the Curse Client need to get smarter, or a new flag in the pkgmeta (call it remove-folder or delete-folder) needs to exist.
Number 2 above is trickier, as in an ideal situation, there is no need to add a new pkgmeta tag, but the Curse Client needs to get smarter about updating and removing unnecessary leftovers. I do realize that if you delete an AddOn that uses a library, the Curse Client will delete the library if no other AddOn uses it. I am talking about upgrading an AddOn, not deleting one. During the upgrade process the system is not smart.-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorSomething that would be useful would be a way to embed libraries that don't have standalone versions on Curse (or at all). Currently the only ways to handle that situation are (a) turn off -nolib packages for your addon or (b) hard-embed the library file in your repository. Neither are ideal. LibDataBroker is a well-known example of an addon that doesn't have a standalone version, but the same issue makes it tricky to use libraries that aren't hosted on Curse, as listing them as externals causes them to be left out of -nolib packages, resulting in users simply not getting the libraries the addon needs, or having to go to google to find them themselves on other sites. This could be fixed with the addition of a new .pkgmeta field for listing externals that should still be included in -nolib zips, or by automatically assuming that any externals coming from non-Curse repositories should still be included in -nolib zips.
-
View User Profile
-
View Posts
-
Send Message
Admin-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorThis is not going to work, at least not in the "packager". It still has to generate ZIP files which need to be the same general addon layout as always before, which means you can just unpack them into the Interface/AddOns folder and be done with it. The packager cannot move anything out of this structure.
That said, the Curse Client could still somehow offer this with some other magic, however not something the packager does.
PS:
Replacing WoW assets is a "questionable" practice at best, imho.
If you write a "UI replacement" and can't shove your initial settings into a normal addon, you shouldn't be writing this stuff in the first place. Curse Client messing with the SVs directly is going to hurt someone!
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorAnother example might be my own SmartRes2. When I switched from LibResComm to LibResInfo, when the Curse Client updated SR2, it left LRC installed. LRC is not LoD.
Nothing questionable about replacing files to mute obnoxious and unnecessary sounds -- like that @#$%ing Millhouse Manastorm toy that shouts stupid things in that horrible horrible voice -- and there's no other way to do it.
Hmm, you're right, but there's still a problem with library dependencies -- if LDB is the only library the addon uses, for example, you also need LibStub and CallbackHandler, but since those are hosted on Curse, they are not included in the -nolib package, and the addon will fail to load.
-
View User Profile
-
View Posts
-
Send Message
Adminexternals: libs/LibStub: url: svn://svn.wowace.com/wow/libstub/mainline/trunk tag: latest embed: yesThen you wouldn't need to hard-embed anything in your addon. The .pkgmeta instructs the packager to always include the external checkout in the package, -nolib or not.
-
View User Profile
-
View Posts
-
Send Message
AdminAt present we can work around that problem by (as you pointed out earlier in this thread or in the other one) using non-Curse external URLs or by hard-embedding, but hard-embedding is far from ideal, and using non-Curse URLs only partly solves the problem unless you're willing to set up non-Curse mirrors for libraries, which seems like an obviously bad practice. It would just be better to have an official solution that's actually a solution rather than a clumsy workaround.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorEither that, or my previous suggestion, which could be a "check all dependencies" flag in the pkgmeta. If not match is found, delete the dependencies.
This will happen again to Archy when Torhal has finished the code to invalidate LibBabble-DigSites-3.0.
I have seen this behaviour in the Curse Client before, as AddOns no longer require dependencies. It happened with Ace-Ace2-Ace3 (yeah, different updaters, point still valid for current Curse Client) and several other cases.
On a side note, given that when Blizzard patches the game and significantly alters previous APIs, historically library files get updated before the AddOns that depend on them. Therefore, I suggest to alleviate (not eliminate) user frustration, the Curse Client should default to no-lib-strip installations, and have embedded as the option. Reverse of the status quo.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorLibraries like this should be Load-On-Demand anyway, so they wouldn't load in the game anymore when they are no longer used.
Not a good idea. Libraries are embeddable to remove them from the user's concern, which is good because it reduces the amount of technical understanding the user needs to install and use libraries -- even if the Curse Client installs libraries for the user, they still have to see them and think about them when using the in-game addon manager to enable or disable addons.
For example, the average Bartender4 user doesn't know or care what libraries are. If they suddenly start seeing 9 extra folders -- Ace3, CallbackHandler, LibActionButton, LibButtonGlow, LibDBIcon, LibDualSpec, LibKeyBound, LibStub and LibWindow -- in their addon list, they're going to be really confused; they might disable or even delete those libraries (because they don't know what they're for) and then be frustrated when Bartender4 doesn't work; and they're likely to (incorrectly) start viewing Bartender4 as "bloated" because it uses so many libraries, and the average user doesn't understand how libraries work any more than they understand the real effects of static memory usage -- and frankly, they shouldn't have to understand those things, or have it shoved in their faces that stuff is going on that they don't understand. The technical stuff should just be hidden away where they can't see it and don't have to think about it.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium