Please stop using FileIO registry internal variables

[nhz2]

This is a very fragile use of FileIO internals.

ExcelFiles.jl/src/ExcelFiles.jl

Lines 10 to 32 in c31a08d

	function __init__()
	# Since FileIO PR #439 (July 2026) the central FileIO registry routes
	# format"Excel" to XLSX.jl's own FileIO extension, and no longer covers
	# legacy xls files at all. Loading ExcelFiles puts its loader first
	# again, and registers a format for xls files. Users who don't load
	# ExcelFiles are unaffected.
	try
	loaders = get!(Vector{FileIO.ActionSource}, FileIO.sym2loader, :Excel)
	filter!(x -> x !== ExcelFiles, loaders)
	pushfirst!(loaders, ExcelFiles)
	savers = get!(Vector{FileIO.ActionSource}, FileIO.sym2saver, :Excel)
	filter!(x -> x !== ExcelFiles, savers)
	pushfirst!(savers, ExcelFiles)
	if !haskey(FileIO.sym2info, :ExcelLegacy)
	FileIO.add_format(FileIO.format"ExcelLegacy", (), [".xls"],
	[:ExcelFiles => Base.UUID("89b67f3b-d1aa-5f6f-9ca4-282e8d98620d"), FileIO.LOAD])
	end
	catch err
	@warn "ExcelFiles could not register itself with FileIO. Loading Excel files via FileIO.load may not use ExcelFiles." exception = (err, catch_backtrace())
	end
	return nothing
	end

It will probably break in the future. Please make a PR to FileIO instead of doing this.

[davidanthoff]

It is a temporary workaround until the FileIO registration situation is sorted out. Someone removed the FileIO registration for this package without even pinging me on the relevant thread, which seems really not ideal, as that breaks the entire Queryverse story for it. I'm not sure how that is going to be resolved, but in the meantime I needed something to at least have tests here run.

[TimG1964]

Someone is probably me. I'm not sure what the relevant thread is but I made several PRs here to try to resurrect this package (#63, #64) which hadn't worked at all for several years. I posted on Discourse asking about this. And I had a discussion on github about how best to support .xlsx files in FileIO.jl. I made clear my preference for continuing with ExcelFiles.jl.

I pinged you directly in the PR you made on XLSX.jl asking if you'd respond to my PRs here.

I had no response from you to any of this.

After extended discussion on github, @SimonDanisch merged my PR switching to XLSX.jl directly.

I don't think it is very fair to blame me for not reaching out when I tried and tried but got no response and when ExcelFiles.jl had already been broken for years.

Very happy to join a sensible discussion on options going forward.

[TimG1964]

Given ExcelFiles relies on XLSX.jl anyway, is there any reason not to stick to XLSX directly from FileIO for .xlsx files and just register ExcelFiles for legacy .xls files only? As an added bonus of doing this, the XLSX package extension has also implemented a transpose keyword, addressing one of the other issues here (#12) and also has an overwrite kw (#24).

[davidanthoff]

@TimG1964 sorry, I didn't want to blame you. I do think FileIO should probably have some formal process in place before something is switched out like that, i.e. some very loud "Hey, if you don't react, we will drop your package from here" type message ;) But that is obviously not your obligation :)

ExcelFiles has a lazy architecture by default, which is important for the wider queryverse integration, in particular with the almost ready https://github.com/queryverse/QueryDuckDB.jl. XLSX.jl is fundamentally eager, which I think is the right call for that package. So I think in my ideal world we would revert the registration to reenable the queryverse story, and I've now tried to add additional features to ExcelFiles that hopefully make that a feature parity switch, i.e. transpose and file overwrite in line with FileIO conventions should work now. I think that would enable essentially the same experience for anyone who is using the current XLSX.jl based FileIO story that has been in place for a few weeks, plus it would reenable the entire original queryverse story.

Oh, and then the other main difference is that ExcelFiles (via ExcelReaders) does support legacy xls binary files, but no longer depends on the problematic Python package for that but instead uses a Yggdrasil shipped binary, so I think that should make it much less likely that things break again in the future.