test for presence of library

test for presence of library

[Harry Putnam]

Can one test for the presence of a library before requiring it?

I mean in the way one might test for the presence of a file in common
shell script; if [ -f /my/file ];then
                  blab blab
              fi

Only here we are testing for the presence of a library somewhere in
the load path rather than a specific file location.

The lisp equivalent of:

 if some-lib 
 then
    (require some-lib)
 fi

Re: test for presence of library

[Lennart Borgman]

On Thu, Feb 18, 2010 at 11:56 PM, Harry Putnam <reader@newsguy.com> wrote:
> Can one test for the presence of a library before requiring it?

locate-library

Re: test for presence of library

[Pascal J. Bourguignon]

Harry Putnam <reader@newsguy.com> writes:

> Can one test for the presence of a library before requiring it?
>
> I mean in the way one might test for the presence of a file in common
> shell script; if [ -f /my/file ];then
>                   blab blab
>               fi
>
> Only here we are testing for the presence of a library somewhere in
> the load path rather than a specific file location.
>
> The lisp equivalent of:
>
>  if some-lib 
>  then
>     (require some-lib)
>  fi


require does the test itself!

C-h f require RET


Now, assume that we wrote:

(when (library-exists-p 'some-lib)
   (require 'some-lib))

and that just after your emacs executed (library-exists-p 'some-lib)
and returned true, some other process would delete that some-lib.el
file.  What would happen to your (require 'some-lib)?


That is, basically, your above shell script with if [ -f /my/file ] is
just WRONG!  If you see such tests in scripts, you are allowed to think
poorly of their authors.



-- 
__Pascal Bourguignon__

Re: test for presence of library

[Harry Putnam]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

[...]

 Harry wrote:
>> The lisp equivalent of:
>>
>>  if some-lib 
>>  then
>>     (require some-lib)
>>  fi
>
>
> require does the test itself!
>
> C-h f require RET
>
>
> Now, assume that we wrote:
>
> (when (library-exists-p 'some-lib)
>    (require 'some-lib))
>
> and that just after your emacs executed (library-exists-p 'some-lib)
> and returned true, some other process would delete that some-lib.el
> file.  What would happen to your (require 'some-lib)?
>
>
> That is, basically, your above shell script with if [ -f /my/file ] is
> just WRONG!  If you see such tests in scripts, you are allowed to think
> poorly of their authors.

Don't hold back, in this case you are allowed and really forced to
think poorly of the author who admits to having literally hundreds of
such tests scattered thru a 10yr accumulation of various scripts in
various scripting languages. 

I'm a known dimwit... its even ok to use the `R' word... I doubt (Sarah
Palin reads this group)

It's ok, I've learned to live with it.

Now lets assume further that we instead say simply:

   (require 'some-lib)

After patting myself on the back for such a wise solution to getting a
needed library loaded, I move to a different and new machine where I've
carted my every ready .emacs file with me.

I start emacs with `emacs /some/path/file'.... but whoops, since
`some-lib' is not in the path in this environment... my emacs blows up
a bit.  It throws up a confusing buffer full of various leads to
information, but none of it appears to bear directly on the job at
hand. .. Not even any indication of what the problem is.

I finally noticed at the bottom, a place to dismiss this interruption
and get back to work.

I'd like to avoid that even though its not really an earth shaking
problem.

My first thought, being a dunce and all, was to test for the presence
of the library before requiring it, thereby smoothing out the work
flow and interruptions. I wasn't sure how that would be done, hence
the question here.

But looking at the suggested documentation I'm left non the wiser:

 (require FEATURE &optional FILENAME NOERROR)

That isn't going to get it for me.. I've tried a few arrangements but
being an idiot and all, I have no idea how something optional is
introduced into the require.

What do you recommend to a simpleton regarding how to avoid the
interruption?  Just make sure all is perfect before starting emacs?

Or maybe spend a day or two figuring out how to apply the codified
documentation.... again... thats' a hard pull for the intellectually
crippled.

Re: test for presence of library

[Dirk-Jan C. Binnema]

>>>>> "HP" == Harry Putnam <reader@newsguy.com> writes:


    HP> But looking at the suggested documentation I'm left non the wiser:

    HP>  (require FEATURE &optional FILENAME NOERROR)

    HP> That isn't going to get it for me.. I've tried a few arrangements but
    HP> being an idiot and all, I have no idea how something optional is
    HP> introduced into the require.


(when (require 'foo nil 'noerror)
      ;; do something with foo
)

is a common pattern to deal with such things.

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: test for presence of library

[Tim X]

Harry Putnam <reader@newsguy.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
> [...]
>
>  Harry wrote:
>>> The lisp equivalent of:
>>>
>>>  if some-lib 
>>>  then
>>>     (require some-lib)
>>>  fi
>>
>>
>> require does the test itself!
>>
>> C-h f require RET
>>
>>
>> Now, assume that we wrote:
>>
>> (when (library-exists-p 'some-lib)
>>    (require 'some-lib))
>>
>> and that just after your emacs executed (library-exists-p 'some-lib)
>> and returned true, some other process would delete that some-lib.el
>> file.  What would happen to your (require 'some-lib)?
>>
>>
>> That is, basically, your above shell script with if [ -f /my/file ] is
>> just WRONG!  If you see such tests in scripts, you are allowed to think
>> poorly of their authors.
>
> Don't hold back, in this case you are allowed and really forced to
> think poorly of the author who admits to having literally hundreds of
> such tests scattered thru a 10yr accumulation of various scripts in
> various scripting languages. 
>
> I'm a known dimwit... its even ok to use the `R' word... I doubt (Sarah
> Palin reads this group)
>
> It's ok, I've learned to live with it.
>
> Now lets assume further that we instead say simply:
>
>    (require 'some-lib)
>
> After patting myself on the back for such a wise solution to getting a
> needed library loaded, I move to a different and new machine where I've
> carted my every ready .emacs file with me.
>
> I start emacs with `emacs /some/path/file'.... but whoops, since
> `some-lib' is not in the path in this environment... my emacs blows up
> a bit.  It throws up a confusing buffer full of various leads to
> information, but none of it appears to bear directly on the job at
> hand. .. Not even any indication of what the problem is.
>
> I finally noticed at the bottom, a place to dismiss this interruption
> and get back to work.
>
> I'd like to avoid that even though its not really an earth shaking
> problem.
>
> My first thought, being a dunce and all, was to test for the presence
> of the library before requiring it, thereby smoothing out the work
> flow and interruptions. I wasn't sure how that would be done, hence
> the question here.
>
> But looking at the suggested documentation I'm left non the wiser:
>
>  (require FEATURE &optional FILENAME NOERROR)
>
> That isn't going to get it for me.. I've tried a few arrangements but
> being an idiot and all, I have no idea how something optional is
> introduced into the require.
>
> What do you recommend to a simpleton regarding how to avoid the
> interruption?  Just make sure all is perfect before starting emacs?
>
> Or maybe spend a day or two figuring out how to apply the codified
> documentation.... again... thats' a hard pull for the intellectually
> crippled.
>

Maybe consider the issue form a slightly different perspective. 

You can have two scenarios when it comes to loading a library

1. If the library is not found, throw an error and let the user deal
with it. The advantage of this approach is that you can be confident
that if no error is thrown, you the library has been loaded and the
features it provides are available. The disadvantage is that if an error
is thrown, the user has to take some action, which may be as simple as
telling emacs to ignore the error and continue. Unfortunately, further
errors could arise when something in your .emacs tries to use the
feature that would have been available if the library had loaded
successfully. 

2. Tell emacs to try and load the library, but don't throw any error if
it fails. This has the advantage that the user does not have to take any
action when emacs can't load the library. However, unless other
precautions are taken, you may get errors further along when emacs tries
to use a feature associated with that library. 

From what you have written, I'm assuming you currently have the first
situation, but would like something more like the second situation. 

both approaches can be handled using require and the predicate featurep. 

The require directive takes an optional second argument 'noerror'. If
you have 

(require 'mylib nil t)

emacs will not throw an error if it fails to find the library 'mylib.
This will give you the first part of a solution outlined in scenario 2.
However, you may still get an error thrown if later lines in your .emacs
try to use a feature that is associated with that library which is not
available. What we need to do is only try to use the feature if the
library was successfully loaded. 

If you look at most libraries, you will find, usually at the end, a line
such as 

(provide 'mylib)

This tells emacs that the feature 'mylib has been loaded. this has two
benefits,.

1. If you have multiple 'require' lines for the same library, it will
only be loaded once as require checks to see if the feature has already
been 'provided'.

2. You can use the featurep predicate to test and see if a library has
been loaded. 

So, the second part of the solution is to ensure that any config or
commands that use features provided by a library always test to see if
that feature has been loaded before trying to use it. 

Yo would end up with something like 

(require 'mylib nil t)
...
...
...
(when (featurep 'mylib) 
      (do-something-using-mylib)
      (do-another-thing-using-mylib))

Whith these two lines, you can use the same .emacs file on different
machines wherre one has the library and one does not and you won't get
bothered with errors at startup. Of course, you could still get errors
when using emacs if you try to use a feature associated with the library
that isn't available, but at least you won't get emacs stalling when it
tries to load.

HTH

Tim




-- 
tcross (at) rapttech dot com dot au

Re: test for presence of library

[Pascal J. Bourguignon]

Harry Putnam <reader@newsguy.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
> [...]
>
>  Harry wrote:
>>> The lisp equivalent of:
>>>
>>>  if some-lib 
>>>  then
>>>     (require some-lib)
>>>  fi
>>
>>
>> require does the test itself!
>>
>> C-h f require RET
>>
>>
>> Now, assume that we wrote:
>>
>> (when (library-exists-p 'some-lib)
>>    (require 'some-lib))
>>
>> and that just after your emacs executed (library-exists-p 'some-lib)
>> and returned true, some other process would delete that some-lib.el
>> file.  What would happen to your (require 'some-lib)?
>>
>>
>> That is, basically, your above shell script with if [ -f /my/file ] is
>> just WRONG!  If you see such tests in scripts, you are allowed to think
>> poorly of their authors.
>
> Don't hold back, in this case you are allowed and really forced to
> think poorly of the author who admits to having literally hundreds of
> such tests scattered thru a 10yr accumulation of various scripts in
> various scripting languages. 

Don't worry, you're better than your self from the past.  We all have
old code that would need big "refactoring"...


> I start emacs with `emacs /some/path/file'.... but whoops, since
> `some-lib' is not in the path in this environment... my emacs blows up
> a bit.  It throws up a confusing buffer full of various leads to
> information, but none of it appears to bear directly on the job at
> hand. .. Not even any indication of what the problem is.


This "blowing up" is the generation and handling of an error.  This
buffer is a backtrace that shows the stack of functions called to reach
the point where the error has been detected.


As an error, it could be dealt generally using operators such as
ignore-errors or condition-case.  But in the case of require, there's
another option.

> But looking at the suggested documentation I'm left non the wiser:
>
>  (require FEATURE &optional FILENAME NOERROR)
>
> That isn't going to get it for me.. I've tried a few arrangements but
> being an idiot and all, I have no idea how something optional is
> introduced into the require.

Now that you know that "blowing up" is really a error being signaled,
The NOERROR parameter should jump at you ;-)

Here, you have two optional parameters.  Since we're interested in the
second, we need to provide the first.

> What do you recommend to a simpleton regarding how to avoid the
> interruption?  Just make sure all is perfect before starting emacs?

So writing:                (require 'some-library nil t) 
or as suggested elsewhere: (require 'some-library nil 'noerror)
since any non null value is true, you will be able to use require
without it signaling any error.  Instead, if there's a problem it will
return nil instead of the symbol of the library.  So you can test it:

(when (require 'some-library nil t)
  (use-that-library))


> Or maybe spend a day or two figuring out how to apply the codified
> documentation.... again... thats' a hard pull for the intellectually
> crippled.

That would be a good investment of your time, indeed.
http://www.gnu.org/software/emacs/manual/
You will have a lot of fun reading the "GNU Emacs manual" and the "GNU
Emacs Lisp reference manual".


-- 
__Pascal Bourguignon__

Re: test for presence of library

[Pascal J. Bourguignon]

Will Parsons <oudeis@nodomain.invalid> writes:

> That's a pretty strong statement.  I use constructions like this in my Emacs
> initialization file:
>
> (when (locate-library "some-library")
>   (require 'some-library)
>
> Why not use the NOERROR argument to require?  Because it doesn't exist in the
> XEmacs version of require, and although I don't use XEmacs a lot, it's nice
> to keep my initialization file compatible between the two versions.

Yes.  Xemacs is broken and makes you write broken code. I'm happy having
decided several years ago not to support it in my ~/.emacs files...

-- 
__Pascal Bourguignon__

Re: test for presence of library

[Harry Putnam]

Sorry for my tardy response... I got distracted for a while.

Thanks posters one and all... good suggestions and great helpful
info.  I have several solutions now.

One case, the one that actually pertains here that didn't get
mentioned by TimX is where something being required is only useful in
certain environments.. 

An example might be using emacs as root when doing system configs.

There are really quite a few aspects of emacs I'll never use in that
situation. Yet its handy to have a portable emacs that loads the stuff
I need in some environments but skips it when working as root doing
system configs.

Or maybe running emacs as user but while setting up a new os where I
won't expect many things to be available... 

In those cases the idea that things may fail down the road from not
loading certain libs is not a problem since those things will not even
be attempted.  

Now I know how to do it.

Thanks to all.

Re: test for presence of library

[Pascal J. Bourguignon]

Harry Putnam <reader@newsguy.com> writes:

> Sorry for my tardy response... I got distracted for a while.
>
> Thanks posters one and all... good suggestions and great helpful
> info.  I have several solutions now.
>
> One case, the one that actually pertains here that didn't get
> mentioned by TimX is where something being required is only useful in
> certain environments.. 
>
> An example might be using emacs as root when doing system configs.
>
> There are really quite a few aspects of emacs I'll never use in that
> situation. Yet its handy to have a portable emacs that loads the stuff
> I need in some environments but skips it when working as root doing
> system configs.
>
> Or maybe running emacs as user but while setting up a new os where I
> won't expect many things to be available... 
>
> In those cases the idea that things may fail down the road from not
> loading certain libs is not a problem since those things will not even
> be attempted.  
>
> Now I know how to do it.

Really, when you are in for a quick edit (vi-like) with emacs as root,
just use:

    emacs -nw -q 

or:

    alias ed='emacs -nw -q'
    ed

;-)
    

-- 
__Pascal Bourguignon__

Re: test for presence of library

[Harry Putnam]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Harry Putnam <reader@newsguy.com> writes:
>
>> Sorry for my tardy response... I got distracted for a while.
>>
>> Thanks posters one and all... good suggestions and great helpful
>> info.  I have several solutions now.
>>
>> One case, the one that actually pertains here that didn't get
>> mentioned by TimX is where something being required is only useful in
>> certain environments.. 
>>
>> An example might be using emacs as root when doing system configs.
>>
>> There are really quite a few aspects of emacs I'll never use in that
>> situation. Yet its handy to have a portable emacs that loads the stuff
>> I need in some environments but skips it when working as root doing
>> system configs.
>>
>> Or maybe running emacs as user but while setting up a new os where I
>> won't expect many things to be available... 
>>
>> In those cases the idea that things may fail down the road from not
>> loading certain libs is not a problem since those things will not even
>> be attempted.  
>>
>> Now I know how to do it.
>
> Really, when you are in for a quick edit (vi-like) with emacs as root,
> just use:
>
>     emacs -nw -q 

Well, yeah for really quick vi-like... but mostly No, not what I was
after... Even there, my .emacs has settings I want in force, such as
custom fontlocking, etc..  and several `skeletons' I use quite a bit.
(Especially when editing configs) Probably quite a few more that would
not be there with -q but don't involve `requiring' extra pkgs.

Particularly one skeleton that wraps original lines with:

  # [HP 10/02/26_14:13:11 
  #  original stuff here
  Type my new stuff here
  # ]

So I can see exactly what was there and what is new for debug
purposes.

> or:
>
>     alias ed='emacs -nw -q'
>     ed
> ;-)

But then I'd miss the joy of doing complicated edits with ed... hehe.