[sword-devel] More installmgr woes... (need for export SWORD_PATH=~/.sword )

Greg Hellings greg.hellings at gmail.com
Thu Sep 3 12:58:07 MST 2009


On Thu, Sep 3, 2009 at 2:29 PM, Jonathan Marsden<jmarsden at fastmail.fm> wrote:
> Matthew Talbert wrote:
>
>> Note that setting SWORD_PATH is *not* the correct way to install into
>> ~/.sword (there isn't a correct way with installmgr, I guess). SWORD_PATH
>> does more things than just that, for instance, locales are
>> loaded from SWORD_PATH/locales.d, ...
>
> I don't think installmgr is fully localized anyway :)  I could just do
> without installmgr (use wget to grab the KJV.zip file and unzip -qod
> ~/.sword/ KJV.zip to install it), for this particular test, but ... surely
> this is exactly the kind of task that installmgr is supposed to do for the
> user, manage installing modules :)
>
> Also I have a similar script installmod.sh that takes a module name as a
> parameter, so I can do installmod.sh WHNU  and get the desired result. I
> could rework that to just use wget and unzip too, I suppose.  It just seems
> a bit silly, when installmgr exists for this very purpose.
>
>> For Xiphos, we support installing into ~/.sword if DataPath isn't
>> writable. We do this by checking it ourselves, ...
>
> OK.  IMO it would have been preferable to get a patch into the libraries,
> rather than work around this in just one front end application.  That way,
> your work and your testing benefits all SWORD apps, not just the one you are
> working on (assuming your patch is accepted, of course!).

Maybe, but there are reasons that those applications which strive to
be cross-platform do a lot of those things themselves.  In order to
support paths with non-ASCII characters, each OS seems to have a
different proper way of doing this.  At least on Win32 the only method
I'm aware of is through calls specifically to the Windows API.  Since
SWORD tries to rely on as few external libraries as possible, it would
need to have lots of #ifdef segments.  A front-end like Xiphos can get
away with a single call to the GTK/GLib libraries which handle those
OS-specific calls for them (and BT could use the Qt classes, etc).  My
understanding is that the InstallMgr library class usually needs to be
extended anyway by most of the applications, so adding the extra calls
at the application level can tackle: (a) non-ASCII usernames, (b) path
read/write permissions checks, (c) transport peculiarities like
proxies, NAT, etc all in one pass, with the support of whatever
external libraries the application is built on (GLib, Qt, XUL, python)
doing the cross-platform lifting instead of trying to figure out every
OS's requirements at the library level.

--Greg

>
>> Secondly, it would be really nice to have a method to install to a certain
>> directory ...
>
> Maybe, although I suspect that if the library did a better job of picking
> the "right" place to install new modules to in the first place, by
> distinguishing between readable data paths (for locales, or for finding
> existing modules, etc.) and writeable ones (for installing, updating and
> deleting modules), then manually specifying an install path would probably
> not be necessary.
>
> Jonathan
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>



More information about the sword-devel mailing list