use extensions for LinearAlgebra, SparseArrays, Test ?

[longemen3000]

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]

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

[longemen3000]

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

[odow]

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]

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

[odow]

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

[odow]

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]

fair enough, thanks for your time addressing this issue.