Repeated precompilation due to Radom package issue

[BoundaryValueProblems]

Under Julia v1.0.1 with SingularIntegralEquations.jl v0.4.0, every time when I start a new Julia session and run using SingularIntegralEquations, it forces to precompile the package even though there is no update. I had a similar problem in our own package recently, and I could resolve this problem by explicitly writing using Random in the source files where some functions in the Random package are used. The following is the warning I get each time I run using SingularIntegralEquations after a new Julia session starts. The situation does not change even after running ] resolve. This happens regardless I explicitly add Random.jl via ] add Random or not.

┌ Warning: Package SingularIntegralEquations does not have Random in its dependencies:
│ - If you have SingularIntegralEquations checked out for development and have
│   added Random as a dependency but haven't updated your primary
│   environment's manifest file, try `Pkg.resolve()`.
│ - Otherwise you may need to report an issue with SingularIntegralEquations
└ Loading Random into SingularIntegralEquations from project dependency, future warnings for SingularIntegralEquations are suppressed.

[MikaelSlevinsky]

I think there's a related issue #114

[BoundaryValueProblems]

I hope this problem will be resolved soon since it takes quite a bit of time to precompile SingularIntegralEquations.jl.

[jwscook]

I'd like to thank for the developers for their time to make this package as great great as it is. I'd like also to re-iterate other's sentiments in hoping that the precompilation issue is fixed soon.

[dlfivefifty]

What in particular do you use? It might be possible to split that functionality out.

I think I know how to work aroundthe issue (in LowRankApprox.jl). I just haven’t had time to do it as there’s a substantial amount of files to change. If you have time I can walk you through what needs to be done.

[jwscook]

I'm using the HyperGeometric functions, specifically mFn. Maybe this could live in https://github.com/JuliaMath/SpecialFunctions.jl?

I might be able to find the time in my 2 x 40 mins on the train every day. What are the steps?

[dlfivefifty]

That's very easy to move out as it is already a fairly self contained module, and all the external package dependencies are superfluous and easily copied over (e.g., FastTransforms.pochhammer). We can put a PR into SpecialFunctions.jl to see if that's the right place, otherwise create a HypergeometricFunctions.jl package. (I'm not sure what SpecialFunctions.jl expectations are for guaranteed correctness.)

So the steps would be:

1. Fork SpecialFunctions.jl
2. Copy over HypergeometricFunctions module
3. Remove dependencies of FastTransforms and ApproxFun by copying over FastTransforms.pochhammer and ApproxFun.@clenshaw
4. Make sure tests are fairly robust
5. Make PR, and if they reject it, we can create a new package HypergeometricFunctions.jl

Alternatively, we could make the new package first and discuss merging into SpecialFunctions.jl later.

[jwscook]

I'll ask right now in SpecialFunctions.jl whether they'll take the HypergeometricFunctions module. Then proceed with either of your options when we hear back.

[jwscook]

You've basically already done this. I've bumped your issue, but it looks as though it'll be most expedient to create a new HypergeometricFunctions.jl package. Is it appropriate to put this in JuliaMath, or are there correctness restrictions on the packages therein?

[dlfivefifty]

I created JuliaApproximation/HypergeometricFunctions.jl and invited you with write access. We can ask to move the repository to JuliaMath later if we wish.