I've been working on an experiment with optimized network traffic when embedding (still not released, but visible via SVN). Instead of fetching externals directly into the stage area it caches the externals in a Externals subdirectory and adds them in when installing the addons. This should reduce SVN network traffic bandwidth even when grabbing addons with embeds enabled since it will only fetch an external once no matter how many addons use it. To support logging it will add additional meta data to the TOC files. One of my goals with addonpkg is to minimize any external traffic.
I'm also adding a currently undocumented option --weak_fetch which doesn't cause caches to be invalidated just because you are fetching new addons. Means you might not get the absolute latest, but should be more network friendly if you the addonpkg -fetch command multiple times in a row.
Some additional ideas I've had for features (none of these are anything more than an idea yet):
Open a web browser to the forum or website for the addon. Not sure there is a defacto standard for a tag for these.
For generating bug reports. Again not sure there is a defacto standard tag. Ideally I'd like addonpkg to find and archive up any save variables for the addon, look for saved buggrabber messages, record SVN version numbers, game version, etc. so that it could be easily sent to the developer.
Show changes made in the stage directory compared to the repository.
Commit changes made in the stage directory for the named addons back to the repository with message of the forum "addon: msg".
I've just uploaded a very quick and dirty beta of addonpkg with all references/support of files.wowace.com removed, and thus it also no longer has a builtin default database for wowace addons. It can still be used as an SVN and GIT updater (see the -svn and -git options and the .addonpkg/addons file). Once details and an API for 3rdparty updaters to wowace are made available I'll look at supporting it.
edit: I installed Algorithm::Diff, then got an error for LWP. I installed LWP but am now getting an error for SVN:Client.pm. I have a feeling my version of perl is just not right or something... maybe because I'm running OS X 10.4 instead of 10.5?
That's likely the case. My guess is that the version of perl in 10.4 has a lot less packages then the version in 10.5. I will probably end up adding a fallback mode for machines that don't have Algorithm::Diff etc. Unfortunately I don't have 10.4 running on any of my machine currently, so I can't really test/check exactly what's available in the base version of perl in that machine.
I haven't had much time to work on this recently and since the latest versions use files.wowace.com in addition to pure SVN and the recent announcements "WowAce's Plans for the Future" may have some impacts on what my script is able to do. I'll probably end up yanking out the files.wowace.com stuff since I've been using the RSS files to know if either if the script should even talk with the SVN servers or even just pull the tar file down from FTP. Unfortunately this means that addonpkg will probably be slower once the SVN is split since it will have to query each SVN/GIT server instead of using the RSS files or other tricks to lower network traffic. For example for SVN servers where a bunch of addons share a common path it has to only send one request to determine which of the addons it should check.
Let me get my windows emulator up and I'll see if I can find the right packages to make it work there again. I'll update this post when I know more.
edit: I just tried reinstalling with the latest ActivePerl and ran into the same problem with installing Alien::SVN, I'm sort of surprised ActivePerl doesn't include it. I might have to look at adding a fall back to the command line for when SVN::Client etc are not present.
This version is sort of halfway between an architecture change so let me know if you run into any problems with it. (I've been moving away from calling the svn command directly towards using Perl modules to do the same thing, but haven't completed that transition yet.)
Version 2008-04-17 is now available. It adds the ability to change the default splitting behaviour from the command line. To do this I had to make another database format change, but as normal addonpkg should automatically update itself. Let me know if you have any issues.
Example to switch to an unsplit version of Ace3 you can run the following commands:
addonpkg -nosplit Ace3
addonpkg -install Ace3
FYI, I've committed a update to my SVN repository of addonpkg that handles the splitting of Ace3 when installing though have not packaged it up yet. There isn't really that much of a need to upgrade however as the current version should work fine as long as you don't mind using the standalone Ace3 addon unsplit.
Version 2007-12-19 is now available. It should offer similar speed ups for fetching addons from other SVNs as the previous version did for fetching from wowace's. Other than that there is no reason to upgrade.
addonpkg -setgroup raid_addons BigWigs oRA2 Omen ...
addonpkg -setgroup solo_addons AuctioneerAdvancedSuite ...
Switch to raid mode:
addonpkg -install raid_addons
addonpkg -uninstall solo_addons
Switch to solo mode:
addonpkg -install solo_addons
addonpkg -uninstall raid_addons
This is also useful for testing compatibly with mutually exclusive groups of addons.
Note set group is additive, so you can do
addonpkg -setgroup groupname A C
addonpkg -setgroup groupname B C D
And A B C D will all be part of the group groupname.
Version 2007-11-13 is now available. New feature enable and disable addons, work with individual modules in addons that split into multiple modules when installed. Aliases as also now available from the command line instead of just the database file. Aliases and groups are very similar in purpose. http://code.google.com/p/nayala-wow/downloads/list
The difference between aliases and groups is that an addon can only be in one group, while addons may be in multiple aliases. When refering to a group by name it only considers the addons in the group that have been previously fetched. Aliases always consider all the addons in the alias. The -setalias command is used to assign addons to aliases.
To enable an addon use the -enable command, for example:
addonpkg -enable -libs MyAddon
would enable MyAddon and all the libraries it uses for all characters you have in WoW.
Disabling is done with the -disable command, for example:
addonpkg -disable MyAddon
Disables MyAddon. Notice I did not use the -libs in this example since that could possibly disable all the addons.
Another example, let's suppose that you are getting ready to update your addons in bulk and are worried that something might break.
Save a copy of your current addons incase you need to restore them.
addonpkg -fetch -all
Update all your addons.
Figure out which addons changed
addonpkg -install -all
Install everything. Log in to wow... Yikes you are getting a bunch of errors... Log out.
addonpkg -disable -all
Disable all your addons.
cd /Applications/World\ of\ Warcraft/Interface/StageArea
addonpkg -enable -libs a*
Enable all the addons beginning with the letter a and their libraries.
Log back into wow, hmm stuff is working. Repeat with b* etc... until you figure out which addon is giving you trouble.
If you don't feel like checking you can always restore your archive with:
Edit: I'm working on a version that uses the RSS feed to avoid fetching addons that have not changed. It's not been packaged up yet but is in revision 87 of my svn at http://nayala-wow.googlecode.com/svn/trunk/addonpkg/ Now available as 2007-11-26 release. This should speed up downloads and reduce load of the SVN servers, let me know if you have any issues with it.
There is a beta at my svn http://nayala-wow.googlecode.com/svn/trunk/addonpkg/ that adds a undocumented option "-mac_mp3_workaround". This option causes mp3 filenames to get mangled when addons are installed to prevent the PlaySound bug. I haven't released the new version yet because there are a few new features that I'm still working on. (I.e. The tar bundle at the site is from an older stable version.)
You can also use addonpkg to install a non-svn addon and mask mp3 files until this bug is fixed using something like.
Brief summary of the other changes (note this stuff is still in flux):
Stage directory is now organized into subdirectories. For example all wowace addons will go under wowace, auctioneer addons under actioneeraddons. You can edit the .addonpkg.addons file to change where addons are played. Just add an -override flag and change the subdir how you wish. You can operate all addons in a subdirectory just by listening that directory name in the list of addons. For example "addonpkg -fetch -revision '<#####' wowace" might be useful to update to revision ##### of addons hosted at wowace.
TOC files are editted when installed to comment out embeds.xml, modules.xml and files that are not present.
TOC files now include information which addon a module came from if it was split using the X-addonpkg-parent tag.
TOC files installed by addonpkg have the X-Package-Manager tag with the value "addonpkg"
.svn directories are no longer copied when installing with addonpkg.
Aliases can refer to multiple addons, for example AuctioneerAdvancedSuite.
Additional dependencies for the -libs option can be harded coded into the addon database. For example: "addonpkg -fetch -libs LightHeaded" gets all the LightHeaded_*_Data addons even though they are not mentioned in the LightHeaded.toc
I've fixed some handling of filename case issues.
Edit: These changes were included in version 2007-10-15
Recently the LoD addons that were embedded in BigWigs got moved to separate folders. This caused the database that addonpkg uses to keep track of the components to be out of date. The fix is to remove the .addonpkg.addons file in your staging directory and then fetching BigWigs and any of the now separate addons you need.