[mojosetup] Questions, bugs, mkdir fix, feature requests

[Ryan C. Gordon]

> First of all, is MojoSetup.installs the intended way of accessing
> options that doesn't modify the filesystem (ie not added to the
> manifest)?  (eg MojoSetup.installs[1].options[1].options .. If so, I
> think accessing installs and options by an id in stead of declaration
> order would be more convenient, eg
> MojoSetup.installs['DROD'].options['base'].options['menuentry'])

MojoSetup.installs is only meant for internal use, and its format will 
change over time (it's generated by some complex filtering and 
validation routines when the config file executes).

We'll need a cleaner way to locate this information for the installation 
hooks, though.

> The naming of the arguments leads me to believe that src is supposed to
> be the file to be linked (the "source" of the symlink), and dst would
> then be the resulting symlink (destination file).

Hmmm...that _is_ confusing. I'm not sure it's not a bug, now that I'm 
looking at it, too. I'll look at it more closely.

> I seem to have run into a bug with options too, but I haven't looked
> at what's causing that yet.  I just can't seem to get more than one
> sub-option of the main required option in my config.lua to show up --
> the extra options are parsed and seemingly recognized by MojoSetup, but
> they don't show up in any of the GUIs (gtk+2, ncurses, stdio).

It's possibly a bug, but it's possible that MojoSetup decided there was 
no scenario where the options could change, so it removed them from the 
UI and marked them as if the user had manually selected them (or not 
selected them, depending). Make sure the "required" and "disabled" 
attributes are both false for the missing option.

Can you post the config.lua for it? I'll take a look.

> MojoPlatform_mkdir would fail in the event that a directory already
> exists (as the FIXME text pointed out), so here's a version that
> doesn't:

Currently everything that uses it checks for existence in the caller 
before calling mkdir(). It might make more sense to have a "cantExist" 
argument, so MojoPlatform_mkdir() only fails if it's important to the 
caller that the directory not exist beforehand.

> * Uninstaller!  Haven't seen this mentioned before for some reason.
>  Making a shell script or whatnot to do the job is easy, but it'd be
>  nice to have a Lua-powered uninstaller, automatically remembering
>  which options was installed etc.

Planned. Likely it'll just be a special command line to the existing 
installer, since it can reuse all the GUI code and scripting, etc.

> * Optional menu entries, desktop icon, etc.  Again, this is pretty easy
>  to do already with xdg-utils and a postinstall function (+uninstaller),
>  but this is such a common thing to do that a built-in way would be
>  nice (not to mention more cross-platform).

It's on the TODO list (even if a given platform might just use xdg-utils 
behind the scenes).

> * A way to write/install generated files through MojoSetup.  This can
>  also be done already with Lua and the io functions, but MojoSetup
>  doesn't update the manifest that way obviously.

That's on the TODO list...the loki_setup_compat script was a first 
attempt at this.

> * Being able to directly access/execute files within an archive
>  from lua would be nice.

Lua scripts can be accessed already with MojoSetup.runfile()...I guess 
we could copy executable things to a temp directory to run them.

> * Detection of existing installations (probably id + install path
>  installed somewhere in $HOME, like loki did with the
>  ~/.<brand>/installed/*.xml symlink .. which is missing from the
>  loki compat btw)

I haven't decided how to do this, yet...I really never liked the Loki 
way, since it breaks when games get moved around, but I'm not sure I 
have a better Unix solution yet, short of implementing Mac OS X's 
LaunchServices framework.

(But obviously, yeah, we'll have a means to use existing loki_setup 
install data eventually.)

> * Updated documentation =).  Seeing a lot of undocumented stuff in the
>  source.

While there could definitely be better commenting in some places, I 
don't have plans for official documentation of the C code beyond 
whatever Doxygen eventually produces from the comments. There will be 
some informal HOWTOs for how to get things done when you need to jump 
between C and Lua for customized installers, etc...generally, most 
installer writers should be able to get anything done in Lua (and when 
they can't, adding general hooks into the C code is more desirable than 
a custom C function), and most of the existing hooks are documented 
already in docs.txt.

--ryan.