Does it grab the latest .zip and send it to the user ? Or does it get files from the repository ? I'd assume the answer is the .zip since it's compressed (saves bandwidth, etc..).
With this assumption, could we imagine that using the required dependency in the .pkgmeta would result in :
1) Packaging the .zip with all dependencies (for manual downloads)
2) Downloading the .zip as it is (with dependencies thus) with the CC, while ignoring the dependencies since they're, by definition, included in the .zip. That is, if "required dependencies" are found in the .pkgmeta.
Now, I don't know if the CC has any visibility on the repository, so this might not be a solution.
At worst, automatic repacking is not the most important for me. I'd be perfectly fine to tell authors to tag their addons every once in a while to make sure they have an updated version of the lib.
Now, on the client side, managing versions could be solved using Mikk's suggestion: each client addons hard-embeds the required modules which would only contain a .toc for the SV file, while all the code could go into a real lib. That way, they could overwrite one another and it wouldn't matter. That's an approach that I intend to test in the future. If that works as I expect, it would solve the problems for updaters as well.
I don't see any easy solution, but since versioning is bound to become an issue in the long run, it's very likely that I'll switch to that design at some point. Thanks for the input btw :)
They're indeed "addons" and not libraries (due to the SV file issue).
There's a .pgkmeta tag where the list of required dependencies are mentioned, so it would be technically possible to let the updaters handle that automatically.
As for the updates, well, I would say that client addons could be repackaged when DS is updated, but then it really depends on how popular it becomes. If it means packaging 10 addons, it's ok, if it's 500, the server load has to be taken into account.
With all due respect for the efforts that have been put into the packagers, I do not agree with the fact that such libs are a bad idea. There is no technical reason on the game's side against the approach, and based on my own experience with the libs (and real life exp with layered dev), it's rather the opposite.
To me, it's the game that should drive the design of an addon/library, not the packaging options/abilities/design choices of external tools.
While I agree with the fact that I must be the only one using this approach, is there a chance to see this supported in the future ? Maybe under the form of a "copy-folders:" tag ?
I agree with Torhal, we had that discussion on IRC back when I finished coding the first versions, and it made more sense to keep them separated as they are now. The only drawback is the one I mentioned: the packaging issue.
I do not know if the method you suggested works, but if it does, it would be the answer to my problem.
The -nolib issue is not too much of a problem for me, since I rely on the presence of libraries into DataStore (ex: ace libs are not in Altoholic, they're in DS), so I could easily disable them.
The Curse Client issue bothers me a bit more, since I'd really like to make sure that an update to either a DS module or to a client addon doesn't lead to unexpected behavior. Some users have told me that some alpha pushes of Altoholic did cause the CC to delete DS modules. If I could get rid of that, the biggest problem would be out of the way :)
Edit: I won't have time to test that this evening, but since Odyssey is still alpha, I'll make packaging tests tomorrow morning. It won't disturb anyone.
For those of you who do not know what they do, their goal is to be data repositories for client addons, so that new developpers don't have to care about which events should be registered to get specific data, or even how to save them in the most efficient way.
A Brief history
I started coding Altoholic a little bit more than 2 years ago, and although I'm a programmer, I did not know anything about Lua, the WoW API, or even the Ace Framework, so I made things work before I made them better.
This meant having to manage a large database full of information, with the annoying consequence that one false move could hurt the DB and result in having to clean the add-on's SV file. That, and the lack of a clean interface to access my data. So after numerous iterations, I thought that adopting a layered/client-server approach could be a solution to my problem, and if it could help other authors at the same time, that would be the cherry on the cake.
How it works
DataStore is the main module, it contains character/guild keys to address the information stored by the other modules.
I have been using DataStore since July 2009, and the biggest advantage I found was that having a single interface to access data is pure bliss from a coder's perspective. There is less need for integrity checks since DS does them for you, and more than anything, data is shared for client addons. I currently use them in two projects, Altoholic & Odyssey, but I'm confident that more addons could benefit from this work.
Another benefit I see is that having a limited number of addons registering the same events avoid conflicts/deadlocks, since client addons basically get rid of this issue. Bag addons, for instance, no longer have to care about which event to register to get bag updates, and especially about when is the right time to do that.
On the other hand, the biggest inconvenient I have faced so far is packaging issues.
At this point, DataStore and its modules are all separate projects, so the svn repository cannot copy them into an addon's package since they would have to be at the same level as the client addon's folder.
Ex: Under Interface\Addons\
This means that release packages have to be assembled manually. It's a pain, but I live with it until I find a better solution...
About the future
.. which is where this post comes into play. As I mentioned above, I have been using DS since last summer, and I intentionally waited until I felt certain that the approach was right before making it a bit more public.
What I need now is a peer review, and suggestions on what is right/wrong. The approach is right, but it's perfectible, and seeing how my backlog is growing, I would gladly welcome more hands on the project :)
Just to give an idea, here are some targets I have for the libs:
Add support for data export (to xml, or whichever format).
Review packaging options. Mikk suggested me to have turn the libs into simple addons that only contain the SV file, and to put all the code into real libs, that's a valid alternative.