search

jump-dev / MutableArithmetics.jl

Interface for arithmetics on mutable types in Julia
Mozilla Public License 2.0
50 stars 8 forks source link

use extensions for `LinearAlgebra`, `SparseArrays`, `Test` ? #298

Closed longemen3000 closed 2 months ago

longemen3000 commented 2 months ago

LinearAlgebra and SparseArrays can be easily migrated to an extension. The Test module seems harder to migrate (stubs for the functions could be created than are populated at extension loading time), but it seems like it is a private API, so changing the requirement of the Test module to be an extension is not so dramatic (considering most uses of test functions are normally used in a context where the Test library is also loaded)

blegat commented 2 months ago

I think this is indeed doable. I never considered it since they were stdlib but it might indeed decrease loading time.

longemen3000 commented 2 months ago

yeah, on julia versions before 1.11, stdlibs were baked into the sysimage, so the loading time was negligible.

odow commented 2 months ago

What is the point of this? In almost all packages that use MutableArithmetics, I would expect some dependency to also load LinearAlgebra or SparseArrays.

longemen3000 commented 2 months ago

I can understand the point about LinearAlgebra and SparseArrays, but what about Test?

odow commented 2 months ago

I'm more open to Test, since that is typically a test-time dependency and it is not used at run-time.

odow commented 2 months ago

The Test module seems harder to migrate

I took a look at this

(stubs for the functions could be created than are populated at extension loading time)

Yip. This is what we'd have to do. But I don't particularly want to.

but it seems like it is a private API,

People use MA.Test.foobar directly, so it's a public API. There's also the issue that it would require people to have using Test, MutableArithmetics, when previously it was possible just to have using MutableArithmetics. Now I admit, this is a very low likelihood of causing breakage, and it would only cause breakage in tests. But it's still a point against moving to an extension.

I think we should close this issue. I don't have plans to fix it. Could we have used a better design for MA.Test? Certainly. But package extensions didn't exist at the time.

Should we fix this in MA v2.0? Yes. By then package extensions will be in the LTS, and we could overhaul our testing to a new system.

But I'm not going to release MA@2 just to fix this test issue. MA is used by >1100 packages, so a breaking change has the potential to cause a large disruption downstream.

longemen3000 commented 2 months ago

fair enough, thanks for your time addressing this issue.