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

[Matthew Talbert]

> 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, it has been brought up. I hesitate to say any more than that,
but what I took away from the conversation was that SWORD was already
flexible enough to deal with any situation required. There were some
changes made after that, but none to address this particular issue
(which was brought up). I don't wish to spend time creating a patch
for something that there is apparently no interest in. Perhaps I
misread the situation, I don't know.

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

No, it only tests to see if the user has permissions to install there.
If they do, then it is offered as an option. If not, it is not
selectable for an install location. It would be nice to integrate
PolicyKit support to elevate privileges, but that hasn't been done.

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

SWORD is at use on several platforms where interoperability isn't a
concern. Besides that, most users aren't even aware that there is more
than one application available. Obviously the situation is different
with the people on this list, but the average user doesn't need 10
different programs reading the same modules.

> 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 :)

Again, there are many cases where that isn't true, such as a
handheld/mobile device. It really isn't true for desktop apps either.
I'd like to be able to install modules in several different locations,
for different purposes and have Xiphos manage them all. I don't really
care whether all the other apps can find the modules or not. We can't
yet do this in Xiphos; we just have the personal/shared options. SWORD
has some support for this. You can add locations to sword.conf, and it
will grab all modules in those locations, but you can't tell it
(easily) to *install* to one of those locations.

You might find it interesting to look back at the discussions about
this. I believe it was around Christmas time.

Matthew