How to handle an optional package that causes build crashes

[Vincent Knight]

Hi all,

*Some background:*

For this ticket http://trac.sagemath.org/ticket/16333, we are working on some new Sage features that inherit from classes from Gambit (http://gambit.sourceforge.net/).

This is making good progress (Ted Turocy from gambit is very keen for this integration and has helped us by making some tweaks to gambit that make things more straightforward: https://github.com/tturocy/gambit/tree/sage_integration).

We have had another ticket reviewed regarding making Gambit an optional package for Sage (http://trac.sagemath.org/ticket/16466) which is also good

*Our question:*

In our current (very much working) branch (https://github.com/theref/sage-game-theory/tree/16333) we are importing Gambit so as to define the corresponding Sage class.

This is all fine (although inheriting from the gambit game class wasn't straightforward) *but* an obvious issue occurs when building Sage without gambit installed.

We're wondering what is the *best practice* for dealing with this is. Error handling in the new module is simple enough but doesn't feel like the right way to do it... 

I'm assuming that there is a way of including conditional build commands in a makefile somewhere (so that the particular piece of game_theory code only compiles if gambit is installed).

Is the above the right way to go about this?

If it is: could someone perhaps point us in the right direction? (There's very little experience on our side with regards to makefiles etc...).

Thanks a lot,

Vince 

[Volker Braun]

I take it you are trying to write a Cython class using a shared library from the Gambit optional package?

Look at the bottom of src/module_list.py, there are already a number of Cython extensions that are only compiled conditionally.

[Vincent Knight]

On 13 June 2014 11:40, Volker Braun <vbrau...@gmail.com> wrote:

I take it you are trying to write a Cython class using a shared library from the Gambit optional package?

That's correct :)

 

 

Look at the bottom of src/module_list.py, there are already a number of Cython extensions that are only compiled conditionally.

Thanks!

--
Dr Vincent Knight
Cardiff School of Mathematics
Senghennydd Road,
Cardiff
CF24 4AG
(+44) 29 2087 5548
www.vincent-knight.com
+Vincent Knight
@drvinceknight
Skype: drvinceknight

[Nathann Cohen]

Look at the bottom of src/module_list.py, there are already a number of Cython extensions that are only compiled conditionally.

Thanks!

Keep something in mind, however : all the documentation contained in those files will *not* appear in Sage's online doc. Which means that users may not even know that the features are available. That's no problem at all if all that you are caching is internal stuff, but if those classes contain a lot of things meant for users, well... No doc :-/

Nathann 

[Vincent Knight]

Very helpful: thanks. Is there another way to handle this and/or get around it?

>
> Nathann 
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/IPRJwPdkuW0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Nathann Cohen]

> Very helpful: thanks. Is there another way to handle this and/or get around
> it?

I cheated in all cases :

For the optinal LP solvers I don't mind as there is a standard LP
solver that exposes the features :

http://www.sagemath.org/doc/reference/numerical/index.html

For the C libraries solving specfic graph problem there is in every
case a method of the Graph class (which appears in the doc). And it
either raises an exception when it is called, saying that the package
should be installed, or solves the problem in a different way.

Whatever you do, add pieces of doc everywhere pointing toward the
absent features and explaining how to install them.

Nothing better. I would like a way to have the doc appear even in all
functions raise an exception, but I don't. If you actually need to
inherit from external code, I'm not very optimistic :-/

Nathann

[Vincent Knight]

On 13 June 2014 12:21, Nathann Cohen <nathan...@gmail.com> wrote:

I cheated in all cases :

For the optinal LP solvers I don't mind as there is a standard LP
solver that exposes the features :

http://www.sagemath.org/doc/reference/numerical/index.html

For the C libraries solving specfic graph problem there is in every
case a method of the Graph class (which appears in the doc). And it
either raises an exception when it is called, saying that the package
should be installed, or solves the problem in a different way.

Whatever you do, add pieces of doc everywhere pointing toward the
absent features and explaining how to install them.

Cool, will keep this in mind. 

Nothing better. I would like a way to have the doc appear even in all
functions raise an exception, but I don't. If you actually need to
inherit from external code, I'm not very optimistic :-/

We've actually just thought of a completely different approach that we _might_ or _might not_ go with. There are advantages (which include not having to deal with this problem at all) and disadvantages that we need to carefully consider (if it's of interest the idea is here: https://github.com/theref/sage-game-theory/issues/48).

With regards to the optional compilation, I might have expressed myself poorly. We've found another solution. Would adding the following to all.py in our game_theory folder be 'acceptable' with regards to general Sage etiquette etc:

from sage.misc.package import is_package_installed
from cooperative_game import CooperativeGame
if is_package_installed('gambit'):
    from normal_form_game import *

normal_form_game.py is the module that imports and inherits from gambit.

Thanks,

Vince

[Nathann Cohen]

Hello !!

> We've actually just thought of a completely different approach that we _might_ or _might not_ go with. There are advantages (which include not having to deal with this problem at all) and disadvantages that we need to carefully consider (if it's of interest the idea is here: https://github.com/theref/sage-game-theory/issues/48).

Well, indeed if you just import functions from the gambit library
inside of your functions then you will have no problem with the doc
:-)

> With regards to the optional compilation, I might have expressed myself poorly. We've found another solution. Would adding the following to all.py in our game_theory folder be 'acceptable' with regards to general Sage etiquette etc:
>
> from sage.misc.package import is_package_installed
> from cooperative_game import CooperativeGame
> if is_package_installed('gambit'):
> from normal_form_game import *
>
> normal_form_game.py is the module that imports and inherits from gambit.

HMmmmmm... Well, I have no idea about Sage's etiquette on this respect :-D

It would be better to import the functions you need inside of each
function, but well.. If it is this or no doc, this is definitely
better ^^;

Nathann

[Volker Braun]

On Friday, June 13, 2014 1:52:58 PM UTC+1, Vincent Knight wrote:

from sage.misc.package import is_package_installed
from cooperative_game import CooperativeGame
if is_package_installed('gambit'):
    from normal_form_game import *

normal_form_game.py is the module that imports and inherits from gambit.

You should try to use LazyImport in all.py to keep the startup time under control. Not everybody is going to want to load the game theory shared library all the time.

If you aim for a Cython wrapper that is generally useful then you could put it into sage.libs.gambit and import from there. But if you just want to import two functions from a big library then I'd hide it away in sage.game_theory.normal_form_game.