Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use historical stdlib dependency information #3911

Merged
merged 4 commits into from
Jul 12, 2024

Conversation

staticfloat
Copy link
Sponsor Member

This makes use of the new functionality in HistoricalStdlibVersions [0]
to properly pull out the dependency information in old stdlibs. This
fixes JuliaPackaging/HistoricalStdlibVersions.jl#9.

[0] JuliaPackaging/HistoricalStdlibVersions.jl#23

@staticfloat staticfloat force-pushed the sf/historical_stdlib_deps branch 6 times, most recently from 34ac794 to 708d9f9 Compare June 3, 2024 06:45
This makes use of the new functionality in HistoricalStdlibVersions [0]
to properly pull out the dependency information in old stdlibs.  This
fixes JuliaPackaging/HistoricalStdlibVersions.jl#9.

[0] JuliaPackaging/HistoricalStdlibVersions.jl#23
@staticfloat
Copy link
Sponsor Member Author

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

staticfloat added a commit to JuliaRegistries/RegistryTools.jl that referenced this pull request Jun 3, 2024
staticfloat added a commit to JuliaPackaging/JLLPrefixes.jl that referenced this pull request Jun 3, 2024
@staticfloat
Copy link
Sponsor Member Author

@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!)

staticfloat added a commit to JuliaPackaging/BinaryBuilder2.jl that referenced this pull request Jun 3, 2024
Workspaces make dependency management so much easier, but tests aren't
passing until JuliaLang/Pkg.jl#3911 is merged.
@DilumAluthge
Copy link
Member

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 ....

@DilumAluthge
Copy link
Member

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

@staticfloat
Copy link
Sponsor Member Author

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.

@KristofferC
Copy link
Sponsor Member

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.

@DilumAluthge DilumAluthge marked this pull request as draft June 17, 2024 22:11
@DilumAluthge
Copy link
Member

Converting to draft so we don't accidentally merge before we remove the "drop me" commits.

@staticfloat staticfloat marked this pull request as ready for review June 18, 2024 02:53
@staticfloat
Copy link
Sponsor Member Author

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.

@staticfloat staticfloat reopened this Jun 18, 2024
@IanButterworth
Copy link
Sponsor Member

@KristofferC merge?

@KristofferC
Copy link
Sponsor Member

Go for it!

@KristofferC KristofferC merged commit 7c0f8c9 into master Jul 12, 2024
14 checks passed
@KristofferC KristofferC deleted the sf/historical_stdlib_deps branch July 12, 2024 18:37
@KristofferC
Copy link
Sponsor Member

(I went for it!)

@IanButterworth IanButterworth mentioned this pull request Jul 13, 2024
JamesWrigley added a commit to JamesWrigley/BinaryBuilderBase.jl that referenced this pull request Jul 19, 2024
This fixes support for nightly with the new Pkg version:
JuliaLang/Pkg.jl#3911.
JamesWrigley added a commit to JamesWrigley/BinaryBuilderBase.jl that referenced this pull request Jul 20, 2024
This fixes support for nightly with the new Pkg version:
JuliaLang/Pkg.jl#3911.
JamesWrigley added a commit to JamesWrigley/BinaryBuilderBase.jl that referenced this pull request Jul 20, 2024
This fixes support for nightly with the new Pkg version:
JuliaLang/Pkg.jl#3911.
JamesWrigley added a commit to JamesWrigley/BinaryBuilderBase.jl that referenced this pull request Jul 20, 2024
This fixes support for nightly with the new Pkg version:
JuliaLang/Pkg.jl#3911.
giordano pushed a commit to JuliaPackaging/BinaryBuilderBase.jl that referenced this pull request Jul 21, 2024
* Add compat with HistoricalStdlibVersions v2

This fixes support for nightly with the new Pkg version:
JuliaLang/Pkg.jl#3911.

* Bump version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Also map the dependencies of stdlibs
4 participants