Register Compiler subfolder of JuliaLang/julia
#118541
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a companion PR to JuliaLang/julia#56409. The two PRs will need to be merged somewhat contemporaneously to allow downstream consumers to transition their use of `Core.Compiler` to the `Compiler` pseudo-stdlib without interruption. As described in JuliaLang/julia#56409, the idea here is rather than using the tranditional Julia stdlib mechanism, which does not track exact package contents or versions, the Compiler instead becomes an ordinary Julia package that just happens to live in JuliaLang/julia (for now). Base has a private copy of this package, but users ordinarily aren't supposed to interact with it. Since it is an ordinary package, it will need to be registered in General, rather than relying on the entry it would have otherwise had in the julia distribution's `stdlib` folder. This PR is intended to facilitate that registration. Note that I am opening this PR without any actual tagged versions of `Compiler`. My intention is to tag `0.0.1` upon merging the corresponding julia PR, but the full versioning strategy for `Compiler` has yet to be decided upon. As mentioned, the purpose of this PR is to get pre-agreement on the registration itself to make sure we can merge/tag simultaneously without doing something overly special on the registry side. I do not know if this PR can be merged as is without any versions tagged or if some part of the tooling will be confused by that. If it can, that's probably easiest. If not, I will amend this PR with the appropriate version once the julia PR is merged and expect it to merge manually shortly thereafter.
CompilerCompiler subfolder of JuliaLang/julia
|
looks like this is missing a compat bound for |
|
I somewhat deliberately left the compat bound off, so packages could depend on it without becoming uninstallable on older julia versions (where they would use Core.Compiler instead). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a companion PR to JuliaLang/julia#56409. The two PRs will need to be merged somewhat contemporaneously to allow downstream consumers to transition their use of
Core.Compilerto theCompilerpseudo-stdlib without interruption.As described in JuliaLang/julia#56409, the idea here is rather than using the tranditional Julia stdlib mechanism, which does not track exact package contents or versions, the Compiler instead becomes an ordinary Julia package that just happens to live in JuliaLang/julia (for now). Base has a private copy of this package, but users ordinarily aren't supposed to interact with it.
Since it is an ordinary package, it will need to be registered in General, rather than relying on the entry it would have otherwise had in the julia distribution's to-level folder. This PR is intended to facilitate that registration.
Note that I am opening this PR without any actual tagged versions of
Compiler. My intention is to tag0.0.1upon merging the corresponding julia PR, but the full versioning strategy forCompilerhas yet to be decided upon.As mentioned, the purpose of this PR is to get pre-agreement on the registration itself to make sure we can merge/tag simultaneously without doing something overly special on the registry side. I do not know if this PR can be merged as is without any versions tagged or if some part of the tooling will be confused by that. If it can, that's probably easiest. If not, I will amend this PR with the appropriate version once the julia PR is merged and expect it to merge manually shortly thereafter.