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

Jonathan Marsden jmarsden at fastmail.fm
Thu Sep 3 13:48:11 MST 2009


Matthew Talbert wrote:

> My point wasn't about localization really, just wanted to point out
> that SWORD_PATH is more far-reaching than simply a way to change where
> modules get installed.

OK, but if you only ever use SWORD_PATH in a script that calls 
installmgr, then that is the only effect it has :)  It may be using a 
sledgehammer to crack a nut, but none of us seem to have found a better way.

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

> Considering that this has been the situation for several years (long 
> before I was around), I can only assume that there is no interest in 
> fixing this in SWORD.

Counterexample: USBINARY was apparently undefined in the Debian/Ubuntu 
SWORD packages well before I arrived.  So encrypted module creation and 
use was (as far as I can see) broken for years.  That doesn't mean there 
is no interest in fixing it (I just did!).

Further, in the case of the install locations, once a couple of apps "do 
their own thing", there may well be lowered interest -- library 
developers may then "assume" that app developers have no interest in 
this functionality being in the library!

Rather than people on either side of the API divide assuming lack of 
interest and creating one-off solutions, it seems much more 
"community-oriented" to ask, or even to create a small patch and then 
ask.  Or maybe I am just a hopeless idealist!

> Well, the SWORD library is meant to be applicable to all sorts of 
> applications, where requirements may vary widely. In our situation,
> we believe in allowing the user to choose whether to install in a 
> system-wide "shared" location, or in a personal location. Having the 
> library choose automatically would decrease functionality for our 
> users. 

So Xiphos now prompts for root privs when needed, so it can write shared 
modules to /usr/share/sword/ ?  Nice, I'll have to try it out!

> Having the ability to easily tell SWORD to install to a certain
> location, would be much better.

OK.  This seems a reasonable use case (though how you determine that a 
particular shared location *would* be writable if you only had root 
privs, without actually asking for those privs first, I do not know -- 
how does Xiphos deal with that?).  It's just that I fear that if you 
allow the API to "install modules to anywhere", someone will then create 
a SWORD app, and arbitrarily decide their modules will all go under 
~/.mynewapp/swordmodules/ or /var/cache/sword_modules/, or whatever, and 
then there will be subsequent user complaints about lack of 
interoperability between SWORD apps, etc.

Libraries are about abstracting away unnecessary details, so when they 
can do so, IMO they should do so.  To keep things somewhat sane, and 
avoid accidents, the library could only permit installing modules to 
SWORD data locations that it knows already exist and are writeable, or 
some similar small set of locations.  Writing out SWORD modules to any 
random path at all is not really what SWORD (and SWORD apps) should be 
doing, IMO.  But then, I am neither a SWORD library developer nor a 
SWORD application developer :)

Jonathan



More information about the sword-devel mailing list