[sldev] Viewer Manifest
rdw at lindenlab.com
Sun Feb 25 02:37:24 PST 2007
Rob Lanphier wrote:
> Hi Ryan,
> Thanks for posting this.
> For everyone else reading this list, I'm hoping you can give your
> comments on this. One way to make it more likely that Lindens engage
> with you on your ideas is when you return the favor.
Thanks for the cheerleading! I am quite impressed by how much depth you
are able to get at without looking at any code.
> Comments inline:
> On 2/22/07 6:49 PM, Ryan Williams wrote:
>> This seems like a great time to interject about an installer packaging
>> script I'm introducing into the next release.
>> The short story is that building an installer will be one step --
>> running a Python script. I don't know how much of our installer-making
>> code has been released, but since the .nsi wasn't, probably "not much".
> Ooops. That certainly wasn't by design. How does one go about building
> the installer? I'm assuming it's just a different build target.
Packaging the installer is not part of the build process anywhere but
Linux. Prior to the viewer_manifest, you built the installer like so:
- On Windows: run the .bat file for the grid that you want the client
to connect to. The .bat files did some housekeeping and then ran NSIS
to generate an exe. I don't know if the .bat files were open-sourced;
- On OS X: 'make -f Makefile_Mac image' called createimage.sh which
built a .dmg.
- On Linux it was part of the client build target.
For backward compatibility, these methods are all rewired to use the
I think there is merit to the notion that building the installer should
be an explicit action, since most builds don't use or need the
installer, so it's just a waste of time unless you're specifically ready
to make a release. Making it an optional part of the build would be
Going forward, the canonical way to package an installer will be simply
running viewer_manifest.py with the appropriate arguments (though it
could be hidden in the build process for sure).
I express here the hope that viewer_manifest.py will not become a
tangled pile of code. The crud I had to write to get the nsi file
generation working correctly is far gnarlier than I'd ever want it to be.
> Has anyone actually tried to build an installer to date?
>> Either way, with the next source release the installer-making
>> capabilities should be fully operational.
> Cool! Let me know which branch you checked your stuff into. Whether or
> not these changes make it into the very next release depends greatly on
> which branch it gets into. Certainly, though, "soon" is a correct answer.
>> I provided documentation for the file here:
>> I'm certainly interested in discussion about the design and
>> implementation of the script. Of course, not much discussion can happen
>> until everyone see the code, but I just wanted to give a heads-up.
> There seems to be plenty there for discussion, actually.
> One question that I have (because I know I'll get asked this down the
> road)...is there existing technology that does this same function that
> isn't too burdensome to switch to? This is a question for everyone, not
> just Ryan. I ask this sincerely, because even though I know this
> problem has been tackled a gazillion times, I also know that the
> solutions out there are often difficult to extract from the projects
> that created them.
> Just to narrow the scope of what would be considered overlapping
> technology, the idea is that this Python script creates a NSIS installer
> on Windows, a .dmg on Mac, and a tarball on Linux, right? Since
> switching installer technologies (at least on Windows and Mac...on
> Linux, something like Autopackage would be kinda cool) is probably
> harder than writing a simple python wrapper from scratch, any viable
> competing technology would need to be able to create an identical
> installer, and have to have the same simplicity of being just a Python
> script (or /maybe/ Perl).
That's the correct scope, though I'm not sure what you mean at the end
there. Do you mean that if we were to find something to supplant
llmanifest, that it would have to be at least as easy to switch to as it
is to pile more functionality into llmanifest?
Something like InstallAnywhere (http://www.zerog.com/)? It looks like
they have an easy 11-step process to building an installer. :-P
> I wasn't able to find anything. If this is truly unique, one thing that
> would be very cool to see is someone take the ball and run with it.
> We're not exactly in the cross-platform installer business, and this
> seems like a problem that a lot of folks have (see
> http://www.wxwidgets.org/wiki/index.php/Installers ). If there's
> someone out there looking to form their own little independent open
> source project, this might prove to be a great starting point (assuming
> Ryan hasn't grown too attached to it just yet). I could see this either
> taking on a life of its own, or perhaps being incorporated in a bigger
That sounds rad to me, though I doubt if this is truly new. I don't
have any plans for developing this outside of our local needs, but I'd
certainly support anyone who's interested in turning it into an
independent project with a life of its own.
> One piece of feedback regarding the platform magic (e.g. derive from
> LLManifest and name your class "HP-UXManifest", and that will be
> selected for use on HP-UX) Platform isn't the only relevant variable in
> choosing which class to use. For example, down the road, we may wish to
> have Linux .rpm, Linux .deb, Linux autopackage, etc. Additionally, it
> may very well be that FreeBSD autopackage and Linux autopackage will
> share more in common than Linux .rpm and Linux autopackage. So,
> building out the class tree based exclusively on platform may not be the
> best thing.
That's a great point. I think you're right -- it should move away from
a class-hierarchy model towards a composition model, wherein you say
something like "llm = LLManifest(); llm.construct =
WindowsManifest.construct; llm.package_finish = MSIpackage_finish".
(yes I know that using semicolons as statement delimiters is so
unpythonic) Using Python's functional features is probably key here.
Then the knowledge about how to find all the files for a particular
platform is decoupled from knowledge on how to bundle them into an
Another thing to consider is making the manifest more
developer-extensible. I hear talk about custom install locations,
custom settings files, etc. All that stuff is hardcoded into the
manifest at the moment, and it would be nice to be able to break them
out into config files, command-line arguments, or something so that
developers don't have to modify the manifest itself just to release a
custom viewer. What are the most useful variables to break out in this
way? I can think of a few:
- Name of app (Install directory on Windows, .app name on Mac, name of
directory in Linux tarball)
- Default command-line arguments to client
- Name/location of settings
- Login screen url (already a command line argument to viewer_manifest)
Thanks for the insight!
More information about the SLDev