JuliaLang
Use historical stdlib dependency information
This makes use of the new functionality in HistoricalStdlibVersions [0] to properly pull out the dependency information in old stdlibs. This fixes https://github.com/JuliaPackaging/HistoricalStdlibVersions.jl/issues/9.
[0] https://github.com/JuliaPackaging/HistoricalStdlibVersions.jl/pull/23
One point of contention here; the Pkg.Types.stdlibs() function seems to be used in the ecosystem, but I like the StdlibInfo struct a lot more than just a random tuple. Should I maintain backwards compatibility, or do we just require package authors to do something like:
if isdefined(Pkg.Types, :StdlibInfo)
stdlib_names = [info.name for (uuid, info) in Pkg.Types.stdlibs()]
else
stdlib_names = [name for (uuid, (name, version)) in Pkg.Types.stdlibs()]
end
@KristofferC If you are happy with this, I will make a breaking v2.0.0 release of HistoricalStdlibVersions, register that, then drop the commit here that manually installs that branch. (Kudos on the [sources] section, super convenient!)
Just to double-check: the Pkg.Types.stdlibs() function is not currently public, right? So in theory we are allowed to make whatever breaking changes we want?
the
Pkg.Types.stdlibs()function seems to be used in the ecosystem,
Skimming that list, it looks like I'm responsible for 4 out of 7 of the usages. I'd be fine with doing a breaking change and then patching my packages to do the requisite if isdefined ....
Just a quick note: a few additional usages pop up if you change the Pkg.Types.stdlibs() (in your search) to Pkg.Types.stdlibs: https://juliahub.com/ui/Search?q=Pkg.Types.stdlibs&type=code
Just to double-check: the Pkg.Types.stdlibs() function is not currently public, right? So in theory we are allowed to make whatever breaking changes we want?
Yes, and perhaps the right thing to do here is to provide a stdlibs_names()::Vector{String} method for people, as it seems that's most of what people want to know. There do seem to be some people who want to check is_stdlib(::String), which we already have inside of Pkg, so it shouldn't be too hard to convert them to a new API if need be.
LGTM but I would prefer leaving the stdlibs etc functions as they were and make new functions for the new info. Just because I know people use Pkg internals a bit all over the place and it seems like there is not a huge gain to modify the existing functions over adding a new one.
Converting to draft so we don't accidentally merge before we remove the "drop me" commits.
Alright, I'm happy with this, the new HSG version has been published and as long as @KristofferC's happy with it, I think we're good to merge.
