[Opensim-dev] Package manager

Diva Canto diva at metaverseink.com
Sun Dec 28 21:51:28 UTC 2014


This works for the region modules themselves, but, as far as I can tell, 
it doesn't work for external dlls on which those region modules depend. 
For example, I have a region module that uses SharpKml.dll, an external 
library. Placing the module's dll and SharpKml.dll elsewhere, and then 
pointing mono addins to that directory loads the module successfully, 
but it fails when code from SharpKml is invoked, because the .Net 
runtime doesn't know where to find it.

So in general we need more than this mono addins directive. My 
preference today is to catch the AppDomain.CurrentDomain.AssemblyResolve 
event in OpenSim, and scan some config-given directory tree when that 
event is raised.

On 12/28/2014 1:38 PM, David Saunders wrote:
> To add a comment to having the dll in one dir.  I use an .addin  file 
> to add other directories to be search for Dlls. This way I separated 
> the addins from the core code and can switch them around just by 
> moving the .addin file.
> This is the example of my current DN.addins  dile.
> <Addins>
> <Directory>/opt/opensimcode/DN-AddIns/</Directory>
> </Addins>
>
> It makes life easyer for testing new core code with out worrying about 
> did i copy all the current addin DLLs over or not.
>
> On Sun, Dec 28, 2014 at 3:45 PM, James Hughes 
> <jamesh at bluewallgroup.com <mailto:jamesh at bluewallgroup.com>> wrote:
>
>     Mono-Addins does 100% of what we need to manage (subscribe to) remote
>     repositories and install plugins hosted in them.
>
>     -BlueWall
>
>     On Sun, 2014-12-28 at 08:43 -0800, Diva Canto wrote:
>     > On 12/27/2014 6:56 PM, Mister Blue wrote:
>     >
>     > > Is there a way to incorporate the NuGet package manager
>     > > (https://nuget.codeplex.com/).
>     >
>     > I looked at Nuget. Nuget is a package manager for VS
>     applications. It
>     > does a lot of things that we don't need, and it doesn't do anything
>     > that we need to do. Essentially, Nuget takes your VS project,
>     and adds
>     > additional dlls in the bin folders and additional lines in
>     .csproj. It
>     > does more .Net things like keeping track of which .Net framework
>     > version the packages are for. It seems very much tied to Visual
>     > Studio, and mono support seems weak. From their FAQ: "Keep in mind
>     > that the focus of NuGet is to let you modify your projects and add
>     > references to Visual Studio projects." [1]
>     >
>     > This is not exactly what we need. We have our own runtime plugin
>     > loading mechanism, region modules. What we need is a package manager
>     > for region modules. Region modules have specific needs, such as
>     having
>     > their own configuration files and their own runtime
>     dependencies. And
>     > they don't have many of the needs that static link-time packages do:
>     > usually region modules don't depend on other region modules,
>     they tend
>     > to be self-contained packages. (although dependencies are possible)
>     > And obviously, they aren't listed explicitly as dependencies of
>     > OpenSim.Region.
>     >
>     > There's a console interface to Nuget that seems to be more
>     inline with
>     > what we need:
>     >
>     http://blog.davidebbo.com/2011/01/installing-nuget-packages-directly-from.html
>     > This seems to be a niche use of Nuget, though, and it doesn't do the
>     > most critical part of what we need, which is to automate the dll
>     load
>     > path and the .ini path. If we use Nuget with this interface, it
>     serves
>     > solely to upload/download packages to/from a central repository,
>     which
>     > I'm not sure where it is, and we'd have to fix the paths by some
>     other
>     > means.
>     >
>     > Nuget is designed to help people incorporate 3rd party libraries
>     into
>     > their own VS projects, which is the kind of activity that we do when
>     > we develop for OpenSim (in Windows). But that's not what we are
>     > talking about here. We need something that helps non-developers
>     > incorporate 3rd party custom plugins into a specific application,
>     > OpenSim. There is no compilation/static link steps at the user's
>     site;
>     > there's just dropping in additional dlls and configuration files
>     > somewhere.
>     >
>     > The question is where those files should be dropped, and how
>     they are
>     > picked up by OpenSim. Dumping everything in bin (which is what Nuget
>     > does) doesn't sound like a good idea and, in fact, we already
>     have the
>     > basics in place to host 3rd party plugins under addon-modules. I
>     think
>     > we should proceed on that route.
>     >
>     > So if someone is interested in figuring out how to hack around Nuget
>     > to make it work well for OpenSim region modules, go ahead. I am not
>     > going to explore that option any further, as what I saw doesn't seem
>     > seem a good fit with what we need. My sense is that in the beginning
>     > Nuget (called Nu) seemed in line with Linux-like package
>     managers, and
>     > at some point it made a sharp turn to become an extension of Visual
>     > Studio.
>     >
>     > (It would also be weird to host OpenSim region modules -- a
>     > specific .Net application's plugins -- in the generic Nuget Gallery.
>     > Region modules aren't useful for anything but OpenSim.)
>     >
>     > [1] http://docs.nuget.org/docs/start-here/nuget-faq
>     >
>     > >
>     > > On Sat, Dec 27, 2014 at 5:37 PM, Diva Canto
>     <diva at metaverseink.com <mailto:diva at metaverseink.com>>
>     > > wrote:
>     > >         On 12/27/2014 3:33 PM, Diva Canto wrote:
>     > >                 Unfortunately, .Net doesn't seem to understand
>     wild
>     > >                 cards in the <probing> element, so the
>     installation
>     > >                 procedure will need to edit this <probing> element
>     > >                 and add the new directory explicitly to the
>     > >                 privatePath, with semi-colon in between, which is
>     > >                 not very nice. But that's Windows philosophy, I
>     > >                 guess...
>     > >
>     > >         We could do this too, and scan everything under
>     > >         addon-modules/*/bin until we find a match. This would have
>     > >         to be done in OpenSim.
>     > >
>     > >
>     http://stackoverflow.com/questions/1561806/looking-for-net-assembly-in-a-different-place
>     > >
>     > >
>     > >  _______________________________________________
>     > >         Opensim-dev mailing list
>     > > Opensim-dev at opensimulator.org
>     <mailto:Opensim-dev at opensimulator.org>
>     > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>     > >
>     > >
>     > >
>     > >
>     > >
>     > > _______________________________________________
>     > > Opensim-dev mailing list
>     > > Opensim-dev at opensimulator.org
>     <mailto:Opensim-dev at opensimulator.org>
>     > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>     >
>     > _______________________________________________
>     > Opensim-dev mailing list
>     > Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>     > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>     _______________________________________________
>     Opensim-dev mailing list
>     Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>     http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20141228/61191dae/attachment.html>


More information about the Opensim-dev mailing list