Closed ChrisRackauckas closed 7 years ago
@ChrisRackauckas thanks for reporting it, let's fix it.
I don't understand from the stack trace you posted what went wrong. Are you talking about a build issue with the C++ library, or is there some problem in the wrapper? By default, the only dependency is GMP. Is that what the problem is?
@certik, this is a build issue in SymEngine.jl. Conda.jl failed to install the symengine libraries. I think the situation would improve with #48.
@isuruf I see. So that's a bug, that we just need to fix. But once we fix it, will it fix this issue? Or are there some conceptual changes that we have to do as well, to make it more robust?
Common practice would be to check for the existence of the deps.jl
file before trying to include it, so if it doesn't exist then you can at least give a better error message.
@tkelman thanks! See #50.
I'm still wondering if there's something safer though. I've had tests failing on AppVeyor for multiple packages for over a week now since they all pull in one package (ParameterizedFunctions.jl) which have one pathway where SymEngine can be used for symbolic manipulations to speed up calculations. However, it allows for the symbolic manipulations to not be possible (since not everything is differentiable), and so all of the SymEngine usage is already in try/catch blocks and the entire package works even if SymEngine doesn't exist.
However, because SymEngine is a dependency that throws an error during precompilation, even though everything would work without SymEngine present / available, none of the packages can even load. That's the behavior that makes it hard to work with.
A build failure would not generate the deps.jl
. deps.jl
is needed at compilation stage only for the constants. Otherwise the errors could be delayed until runtime. Simplest solution would be to not throw an error if an environment variable is set and deps.jl
is missing and to avoid defining the constants for the same conditions.
You can use the tag v0.1.2 which has the fix for this.
I would like to be able to use this library for some features in a larger package, but at present it can have build issues which cause an entire other project to be unusable. Is there a way to "tame" the errors so that way it doesn't crash dependents if unavailable? Maybe @tkelman has an answer. I am trying to avoid conditional dependencies, but something like this, it's hard to use SymEngine to provide additional features if it can cause the entire package to be unusable. Hopefully we can find a better option.