[Opensim-dev] Package manager

[Diva Canto]

On 1/6/2015 8:01 AM, Mic Bowman wrote:
> Updating the Dispatcher and RemoteControl modules to match this 
> uncovered a couple issues... First, do we have naming conventions for 
> files? Collisions are quite possible (e.g. "README" and "LICENSES"). 
> At this point, the example dumps all package files into the bin 
> directory.

That is a problem, but not as bad as you may think. Let me explain when 
it's a problem and when it is not.

- Not a problem: when addins are installed from binary packages, each 
addin is placed in its own subfolder under RegistryLocation/addins. So 
files like READMEs, LICENSES, etc are all safe from collisions. I'm 
assuming the addin developers don't move those files anywhere else; if 
they do, it's their responsibility to know what the heck they're doing.

- Problem: configuration files (.inis) are placed in ConfigDirectory, 
and this may, indeed, result in collisions. My only suggestion is to 
name the ini very closely to the name of the addin.

- Problem-that-isn't: collisions may occur in addin names themselves, 
but that is something that I don't think will happen in practice. All 
3rd party package systems (yum, apt-get, npm, ...) suffer from the same 
potential problem, and communities seem to find ways to avoid name 
collisions, because they don't benefit anyone.

- Problem: when you, as addin developer, develop several addins under 
the same source tree, and you send all these files indiscriminately to 
bin for packaging, you may end up with collisions. This can be easily 
solved in prebuild.xml: copy the files to their own subfolders instead 
of copying them to bin. The example in the instructions copies the files 
to bin, but that doesn't need to be the case; you can copy them 
anywhere. The only important thing for mautil to be able to pack 
everything correctly is that the files need to be in the paths given in 
the addin directives you write in the assembly package. So you can do 
this for each addin:

   (a) send the dlls to bin, if you want, because the changes of name 
collision are null
   (b) send all non-dlls to a subfolder of bin, say addin1-files
   (c) in the addin directives write something like this:
       [assembly: ImportAddinFile("addin1-files/LICENSE.txt")]

If you do this, the final package will have a similar folder structure, 
i.e. people will see
RegistryLocation/addin/YourAddin/
   dlls
RegistryLocation/addin/YourAddin/addin1-files/
   LICENSE.txt

> Its easy enough to put things into package directories... just might 
> be good to ensure thats part of the conventions.

Yes. I don't think we need to make a convention on that. The main 
problem (the last one on my list above) is internal to addin developers.

> Second, is there a way to identify previously installed dependencies? 
> E.g. I have a third party module for parsing JSON that might be 
> installed by other modules.

In my tests, mono addins does the right thing with dependencies! For 
example, Diva.Wifi (which is now an addin) depends on another addin 
Diva.Interfaces (this one defines an extension point for Wifi -- I have 
extra packages that aren't in the free distribution of Wifi). When you 
install Diva.Wifi, it correctly installs Diva.Interfaces automatically. 
The interface is very similar to yum or apt-get, it lets you know about 
the dependencies, and asks you if you want to proceed.