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

[Gerry JJ]

Hi, sorry for not getting back to you before.

> > 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.

Yes, those are both false for the sub-options, but the main option is
marked as required, which turned out to be the problem.  If the main
option is marked as non-required, all sub-options show up as expected.
Still seems like a bug, but possible to work around by moving the
sub-options up a level.  (That's probably not ideal if the required
setting is set by some script result though.)

Setup.Option {
	required = true,
        disabled = false,
	...

	Setup.Option {
		required = false,
	        disabled = false,
		...
	},

	Setup.Option {
		-- invisible, unless parent option is non-required
		required = false,
	        disabled = false,
		...
	},
}

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

Here's a small example:

--- 8< ---
Setup.Package
{
    id = "test",
    description = "Test",
    version = "0",
    recommended_destinations = MojoSetup.info.homedir,

    Setup.Option
    {
        value = true,
        required = true,
        disabled = false,
        bytes = 1,
        description = "Base Install",

        Setup.Option
        {
            value = true,
            required = false,
            disabled = false,
            bytes = 0,
            description = "Install menu entry",
        },

        Setup.Option
        {
            value = false,
            required = false,
            disabled = false,
            bytes = 0,
            description = "Install desktop icon",
        },
    },
}
--- 8< ---

> > 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.

Yeah.  The reason I added it was that my config.lua needed to call
MojoSetup.platform.mkdir to make some extra directories, which doesn't
check existence.  I guess it could've called MojoSetup.platform.isdir
to check first, though having mkdir do the check seemed to be more
user-friendly in general =)

(Later on I discovered that there's some helpful functions in
mojosetup_mainline.lua, btw, but they're local.  I think it'd be
helpful to have at least some of those available from config.lua.)

> > * 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.
[..]
> Whoops, I misread this. Let me think on this one some more. It's 
> probably just small files that need to get written out (like a 
> registration file, etc), so having a way to add to the manifest
> without having to plug into the progress UI might be all it needs...

Yeah, that'd probably be enough.  Although, now that I think about
it, some installers might want to modify/generate larger files on the
fly (a Linux installer patching a Windows game CD while installing,
etc).

> > * 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.

Yeah, I knew about the lua scripts, but being able to execute regular
executables and shell scripts and such would be nice, too (and
accessing data, etc).

> > * 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.

Yeah.  Even with a symlink solution though, it'd only have to get used
(and possibly break) if the uninstaller couldn't otherwise find out
where the game was installed (if it wasn't in the same directory as the
uninstall executable probably).

> > * 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.

Yeah, I was thinking more of the functions exposed to Lua, like for
example the MojoSetup.platform table, which is currently undocumented.

- Gerry