-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Infer resolver version from workspace edition #10587
Comments
@rustbot claim |
@hi-rustin If you don't mind I would like to claim this. I want to add it to the RFC as something to do before we try to stabilize. |
I don't quite understand what you mean? |
I'm currently working on the RFC for workspace inheritance and would like to add this issue to the tracking issue as something to do before trying to stabilize it. |
You mean we don't need to implement it now? (Or is there something blocking it?)
This confuses me 😖 I thought we were going to make it happen now. Unassign myself. |
If it is now acceptable and achievable. Then I'm happy to implement it :( |
That's my bad for being confusing. I was just trying to say that I was just going to add it to my todo list before trying for stabilization of workspace inheritance. If it's something you want to work on you are more than welcome to. There shouldn't be any blockers on it. |
@ehuss my comment in #5784 used the Background: there is unresolved thread from the RFC that I think needs revisiting and so #10564 changed the inheritable syntax to |
Another thing to consider is having |
Ah, sorry for the confusion. I probably should not have marked this with an E tag as this is indeed part of the RFC 2906 work. @hi-rustin, it looks like you have several open issues assigned to you. I recommend trying to finish some of those off before claiming additional issues. I appreciate the interest in helping, but claiming too many issues at the same time can make coordination more difficult. @epage Sorry, I did not see that had changed. That indeed puts a wrinkle in this. I wouldn't want those inheritance fields to have no intrinsic meaning, except for Unless anyone has particular ideas on how to deal with that, I'm leaning towards just closing this. |
Let's at least leave this open until 2906 is stablized in case things change during the stablization. |
I've claimed 4 issues, two of which have PRs waiting for review. another one is just revising the documentation, and the remaining one is also related to workspace, so I was wondering if I could look at this issue together yesterday. sorry to bother you all. I'll avoid this kind of problem next time. |
With workspace inheritance being stabilized, and #10112 being brought up again (#10910 would close it). I was wondering if this was something to consider again before it would be a breaking change. Currently setting |
Triage: I still lean towards implementing #10112 over this for now. I think making It is unfortunate to need the extra boilerplate of the |
It would be very helpful to set the resolver version in a virtual workspace based on the
edition
field being added in RFC 2906. This has been requested several times and has caused some confusion for some users.That is, if you have:
Then this will default
workspace.resolver = "2"
The logic for determining the version is here. It should also check the workspace edition. This should also be gated on workspace-inheritance on nightly.
The text was updated successfully, but these errors were encountered: