Raising exception if glpk is _not_ installed

[johnyf]

Thank you for this change. It looks good to me.

This error was introduced in https://github.com/tulip-control/polytope/commit/caf8c61655ea2c9c101fe29867a24cc0028bfd13#diff-7b1ac28f438b876806216e8120a046db34b027f8d1c02a0aca1ceac1e2a543efR109. The change in this pull request agrees with the initial version of those lines: https://github.com/tulip-control/polytope/commit/125d8da285d473ec2ad15692fe4cac888c27a423#diff-7b1ac28f438b876806216e8120a046db34b027f8d1c02a0aca1ceac1e2a543efR120.

Relevant remarks:

• it seems that the following check for GLPK is redundant, though it allows printing an exception message that is more informative: https://github.com/tulip-control/polytope/blob/b11c5cecf00ae4c8fc5021289460b4cf9cd971a8/polytope/esp.py#L109-L112 The reason is that when the check was moved there (in commit 125d8da285d473ec2ad15692fe4cac888c27a423), the locally defined value of lp_solver (which could have been None https://github.com/tulip-control/polytope/blob/125d8da285d473ec2ad15692fe4cac888c27a423/polytope/esp.py#L62) was passed as argument solver to the function polytope.solvers.lp: https://github.com/tulip-control/polytope/blob/125d8da285d473ec2ad15692fe4cac888c27a423/polytope/esp.py#L155-L157 However, later changes made all calls to the function polytope.solvers.lpsolve from the module polytope.esp pass as argument solver the value 'glpk', for example: https://github.com/tulip-control/polytope/blob/b11c5cecf00ae4c8fc5021289460b4cf9cd971a8/polytope/esp.py#L144 This ensures that in case GLPK is not available, then all calls from module esp will fail by raising the exception: https://github.com/tulip-control/polytope/blob/b11c5cecf00ae4c8fc5021289460b4cf9cd971a8/polytope/solvers.py#L152-L155 So the check in function polytope.esp.esp duplicates that check in the function polytope.solvers._assert_have_solver. Nonetheless, this check may be worth keeping, in order to print a message that explains that GLPK is a requirement of the module polytope.esp (instead of having the user wonder why the exception was raised, if they did not request GLPK in their code).
• the function polytope.esp.esp raises an Exception: https://github.com/tulip-control/polytope/blob/b11c5cecf00ae4c8fc5021289460b4cf9cd971a8/polytope/esp.py#L110 whereas the function polytope.solvers._assert_have_solver raises a RuntimeError: https://github.com/tulip-control/polytope/blob/b11c5cecf00ae4c8fc5021289460b4cf9cd971a8/polytope/solvers.py#L152 The message of commit caf8c61655ea2c9c101fe29867a24cc0028bfd13 describes the rationale for choosing RuntimeError instead of ImportError. Based on the documentation of RuntimeError, it may be more suitable to raise a RuntimeError instead of an Exception when checking within the function polytope.esp.esp whether GLPK is available.

Before merging, I would like to note that GitHub does not appear to associate the commit 722ff00b805d86e864c9bfcfec3229032fd04586 with any GitHub account. If it is intended to associate the commit with your account, then please consider either:

• adding the email used in the commit to your GitHub account (as described here), or
• force pushing a commit with the same changes but another email address that is associated with your GitHub account.

If no email-related change is needed, then I will merge this pull request.

[murrayrm]

@krooken Let us know if you want to add an e-mail to the commit.

@johnyf I suggest we give @krooken a few days, then merge.

[krooken]

I've added the new email to my GitHub account, so it should be good to go now.

[johnyf]

Thank you for the update. Merged as f981f434a270ee005076b9c534383aeaba314f40.