Closed mkitti closed 8 months ago
@staticfloat , I would appreciate your review here.
I agree that this could be breaking. What I would like to figure out is specifically how so? The test suite does not seem to capture it.
If we do find this unretrievably breaking, then that provides cause to push https://github.com/JuliaLang/julia/pull/52249 further. It also provides a direction to improve the test suite.
The main break I could see is if the former constructors were actually expected to create a distinct type or not. It is not clear to me from the tests that this is clearly the case.
I just tried Blosc v0.6.0 that uses BinaryProvider v0.5.10 and everything seems to working as expected. I'll try some older packages and JLLs and see if I can get this to break.
(testenv) pkg> st
Status `~/src/Pkg.jl/testenv/Project.toml`
⌃ [a74b3585] Blosc v0.6.0
[44cfe95a] Pkg v1.11.0 `..`
(testenv) pkg> st -m
Status `~/src/Pkg.jl/testenv/Manifest.toml`
[9e28174c] BinDeps v1.0.2
[b99e7846] BinaryProvider v0.5.10
⌃ [a74b3585] Blosc v0.6.0
...
julia> using Blosc
julia> Blosc.compress(rand(0x0:0x1, 1024)) |> length
568
Actually, I do not think BinaryProvider is a problem here. The last released version was v0.5.10 which did not contain any references to Pkg.BinaryBuilder: https://github.com/JuliaPackaging/BinaryProvider.jl/tree/v0.5.10
The master branch does contain a reference, but it was never released as far as I can tell.
Thus I think it is only the old BinaryBuilder JLLs that we need to check. That's promising since most of those are probably auto-generated and quite regular.
I found an example where this would break a relatively new package: https://github.com/PeaceFounder/AppBundler.jl/issues/4
Searching for symbols, AppBundler.jl is the only registered package I could find that actually tries to dispatch on the types.
https://juliahub.com/ui/Search?q=MacOS&type=symbols https://juliahub.com/ui/Search?q=Windows&type=symbols https://juliahub.com/ui/Search?q=Linux&type=symbols
I created a pull request to modify AppBundler.jl to not dispatch on the types.
I do not think they should be removed.
To be clear, Base.BinaryPlatforms
removed it a long time ago, because it was found to cause a lot of unfortunate compile time. These compat adapters have been in place since then to allow legacy code to continue to use it, but I would encourage all users to move away from the per-OS types to the unified Platform
type. Not only is splitting the type based on OS bad for compile time, it's also kind of an arbitrary choice when there are lots of other ways to split platforms (architecture, libc, libgfortran version, etc...) that are much better represented with the unified Platform
object.
I do have another idea in mind. There is not a strong reason why we need to extend either the Base.BinaryPlatforms
types or APIs. We could have a separate type hierarchy which converts and forwards to the Base
methods.
I will try that as another pull request.
I tried again, keeping the types this time: https://github.com/JuliaLang/Pkg.jl/pull/3742
I will close this in favor of that.
In https://github.com/JuliaLang/julia/pull/52249 I proposed moving the
Pkg.BinaryPlatforms
to base in order to fix invalidations.Here, I pursue an alternate route and refactor
Pkg.BinaryPlatforms
. In particular, I eliminate theAbstractPlatform
subtypes.UnknownPlatform
,Linux
,Windows
,MacOS
, andFreeBSD
are now just methods that return Base.BinaryPlatforms.Platform instances.No methods are imported from
Base.BinaryPlatforms
and no methods are overloaded.arch
,libc
,call_ab
,cxxstring_abi
which used to be methods ofBase.BinaryPlatforms
are now just independent functions belongPkg.BinaryPlatforms
. ThePkg.BinaryPlatform
versions returnSymbol
orNothing
. TheBase.BinaryPlatform
versions returnString
orNothing
.The
test/binaryplatforms.jl
test suite passes without modification.Demonstration: