The only examples of required-dependencies syntax I've seen list the "slug" name and nothing more.
Can the entries in req-dep specify a tag, like the entries in the externals section? Or do req-deps always default to... whatever the downloader feels like defaulting to?
I would argue that it's mostly so that the curse client will automatically download and install the dependencies if they're not present. I don't give a rat's ass what it displays. I would, however, like to make sure that they're downloading the right versions.
My own addon checks their versions and alerts them when appropriate, but if the updater could Do The Right Thing in the first place, it'd be an even smoother user experience.
This sounds like a bad idea. The Curse Client should always install the latest dependency anyway. Adding another layer of complexity in there would be weird.
In any case, its more a Curse Client request then a packager request.
I have an addon which makes use of other addons (therefore, they're not embedded externals, just dependencies). I've coded my addon against the API of the latest *released* version of those addons. Users installing my addon via CC were automatically given the released version of the other addons, and all was well.
Then I got some bug reports from users who had ended up with my addon and the *beta* versions of the others, apparently due to a CC setting somewhere. They had no other addons depending on or requiring them (and so nothing else to pull in the addons at all, let alone specifically requesting beta versions). The API is in the middle of changing and it caused all kinds of bizarre errors in my own addon until I figured out what had happened.
So, if CC is going to pull down dependencies that it would not otherwise pull down, I'd like to tell it "get *this* tag, not the absolute latest". And if it turns out that some other addon requires a more recent version, I'd be okay with CC telling the user that it cannot download my addon due to conflicts; under those circumstances it would be my responsibility to handle the new, presumably stabilized, API in use.
Did that make any sense or should I have finished my coffee before typing?
Possibly this situation is rare enough that we don't need tools capable of handling it for us.
What's wrong with bug reports about beta versions? Presumably a beta version is fairly "final" in terms of what the author wants to release. Or, just post a note on your addon page stating that you won't provide any support for anything related to non-release versions, and ignore the users who can't read.
Phanx, I think he meant that the user used a release version of *his* addon but the beta version of the dependencies (where the his addon expected a release version), e.g. : GridFarmbuyerIndicator release 5 expects Grid 1.40000.1403 but the user actually installed Grid r1406, which breaks GridFarmbuyerIndicator.
Phanx, I think he meant that the user used a release version of *his* addon but the beta version of the dependencies (where the his addon expected a release version),
Exactly. I coded in some runtime checks, but if we can avoid the situation altogether, or have CC tell the user it's not going to work instead of waiting until the user logs in and trips the runtime checks, it'd be an improvement.
Yes, I'm aware of that. But if your addon depends on AddonX, and there's a new beta version of AddonX, I think it's pretty likely that any changes in the beta version of AddonX that require changes in your addon are going to make it to the next release version of AddonX, so you should probably just update your addon.
If your addon depends on another addon, it's YOUR job to keep your addon up to date with changes in the other addon, NOT the user's job to keep track of changes and compatible versions, and NOT the packager's or the Client's job to force users to download old versions.
If you don't want to update your addon for some reason, it's still YOUR job to make sure your addon doesn't try to work with newer versions of the other addon that it was written for.
What's next, proposing to prevent users from downloading an addon that was packaged with r32 of a library if you already have another addon that was packaged with r38 of the same library?
If AddonFoo-5.2 stritcly depended on AddonBar-3.1, installing AddonBar-3.2-beta would likely break AddonFoo-5.2, even if there was an upcoming version of AddonFoo that would be compatible with the new AddonBar-3.2-beta API.
With the CC, this will happen automatically if the user configured AddonFoo to "release" and AddonBar to "beta". This could be solved by in-game warning from AddonFoo or maybe in the CC. Strictly requiring a version seems overcomplicated but emitting a warning about incompatible addons could be helpful.
Yes, I'm aware of that. But if your addon depends on AddonX, and there's a new beta version of AddonX, I think it's pretty likely that any changes in the beta version of AddonX that require changes in your addon are going to make it to the next release version of AddonX, so you should probably just update your addon.
Work on those beta addons has stopped. If there were any visible signs of progress towards a new stable API, then of course I would update my own code. Maybe the author's taken a short break, maybe left the game entirely, maybe something in between. I don't know.
As it stands, I have a choice of supporting the coordinated released versions, or a mishmash of beta versions which might not ever converge. So, no. When and if they are stabilized and released, then I'll invest my free time into the new API. In the meantime, I was wondering if pkgmeta already supported this feature with undocumented syntax. If not, then not.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCan the entries in req-dep specify a tag, like the entries in the externals section? Or do req-deps always default to... whatever the downloader feels like defaulting to?
as such it does not care about tags
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMy own addon checks their versions and alerts them when appropriate, but if the updater could Do The Right Thing in the first place, it'd be an even smoother user experience.
-
View User Profile
-
View Posts
-
Send Message
Project Author-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's a rather good new, I hope. *crosses fingers*
-
View User Profile
-
View Posts
-
Send Message
Project Author-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorIn any case, its more a Curse Client request then a packager request.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI have an addon which makes use of other addons (therefore, they're not embedded externals, just dependencies). I've coded my addon against the API of the latest *released* version of those addons. Users installing my addon via CC were automatically given the released version of the other addons, and all was well.
Then I got some bug reports from users who had ended up with my addon and the *beta* versions of the others, apparently due to a CC setting somewhere. They had no other addons depending on or requiring them (and so nothing else to pull in the addons at all, let alone specifically requesting beta versions). The API is in the middle of changing and it caused all kinds of bizarre errors in my own addon until I figured out what had happened.
So, if CC is going to pull down dependencies that it would not otherwise pull down, I'd like to tell it "get *this* tag, not the absolute latest". And if it turns out that some other addon requires a more recent version, I'd be okay with CC telling the user that it cannot download my addon due to conflicts; under those circumstances it would be my responsibility to handle the new, presumably stabilized, API in use.
Did that make any sense or should I have finished my coffee before typing?
Possibly this situation is rare enough that we don't need tools capable of handling it for us.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumExactly. I coded in some runtime checks, but if we can avoid the situation altogether, or have CC tell the user it's not going to work instead of waiting until the user logs in and trips the runtime checks, it'd be an improvement.
If your addon depends on another addon, it's YOUR job to keep your addon up to date with changes in the other addon, NOT the user's job to keep track of changes and compatible versions, and NOT the packager's or the Client's job to force users to download old versions.
If you don't want to update your addon for some reason, it's still YOUR job to make sure your addon doesn't try to work with newer versions of the other addon that it was written for.
What's next, proposing to prevent users from downloading an addon that was packaged with r32 of a library if you already have another addon that was packaged with r38 of the same library?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWith the CC, this will happen automatically if the user configured AddonFoo to "release" and AddonBar to "beta". This could be solved by in-game warning from AddonFoo or maybe in the CC. Strictly requiring a version seems overcomplicated but emitting a warning about incompatible addons could be helpful.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWork on those beta addons has stopped. If there were any visible signs of progress towards a new stable API, then of course I would update my own code. Maybe the author's taken a short break, maybe left the game entirely, maybe something in between. I don't know.
As it stands, I have a choice of supporting the coordinated released versions, or a mishmash of beta versions which might not ever converge. So, no. When and if they are stabilized and released, then I'll invest my free time into the new API. In the meantime, I was wondering if pkgmeta already supported this feature with undocumented syntax. If not, then not.