Move more packages to weak dependencies#693
Conversation
|
I've taken a look at this now and I think removing StaticArrays as a dependency would be too annoying to pull off: too many methods use it internally for speed. RecursiveArrayTools, on the other hand, should be doable without major issues. Another dependency I'd prefer to have as a weak one is Distributions.jl. I expect to have enough free time in August to push for a breaking release containing transition to weak dependencies + Oliver's PR (with polishing). What do you think? |
|
Yes, now that I noticed that Oliviers PR is breaking, we could combine that with this PR and check a bit what else to break since we are at it ;) Thanks for looking into it. |
|
We could for example also do #701 then. That should even be a quite short PR. |
|
Yes, #701 could also be done, or any other quick and breaking thing we intended to do. |
|
#732 is now merged and supersedes this PR so we can close this. |
As discussed in #656, this is an idea to move two further packages to weak dependencies.
I am not saying we should necessarily do that, but it is something to discuss, and I for now just spent about an hour to reorganise the code. I am not yet sure the advantages outweigh the disadvantages here
This would be a breaking change
ArrayPartitionwill no longer be exported in Manifolds.jlBefore checking and adopting the tests I would like to discuss whether we actually want to do this, with the disadvantages above the question is, does the reduced loading time make this worth the change?