-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Remove support for packages directory #30384
Comments
Why is this P1? |
It's cleanup that would be ideal in v2 – since it'll be easier to get away with breaking changes. |
Any updates on this, @kevmoo ? |
@kevmoo will follow up on this to see what users would be affected. |
@MichaelRFairhurst any updates here? |
I don't think I'll be able to take this on in two weeks in addition to my other work. I did ask on the design doc to confirm that we'd only need to do wave 1 in the meantime; however, even if that's true, I imagine tracking down those APIs to deprecate and publish could easily go wrong. For instance, package:analyzer has a near copy of package:package_resolver (in order to use a different file system API). I need to see if that's public, and if it is, that needs to be deprecated & published too. |
Any updates on the plan here? |
I have not yet had time to take a look, been putting all my time into #33221 |
Part of #30384. This was usually not a problem as most cases involve additional visitors which rewrite this (for instance, inference). However, in some cases (appears to be summaries only), that extra resolution is not needed/skipped, so the non-instantiated constructors remain. That makes the constantValue of annotations vulnerable to this, and the resulting DartObject types will have 'TypeParameterType's for there typeArguments. Instantiate the types to bounds, and get the ctor from the type rather than the element, inside of AstRewriter in order to ensure these constructors are instantiated. Change-Id: I65f55feb751e139e68c774786bfbc53788d32995 Reviewed-on: https://dart-review.googlesource.com/58800 Reviewed-by: Konstantin Shcheglov <[email protected]> Commit-Queue: Mike Fairhurst <[email protected]>
Strawman CL, which seems to have no issues internally: https://dart-review.googlesource.com/#/c/sdk/+/59100 |
Can this issue be closed at this point? |
Should we leave it open to actually remove the APIs? They are just
deprecated + noop now...
…On Thu, Jun 14, 2018 at 2:17 PM Dan Grove ***@***.***> wrote:
Can this issue be closed at this point?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#30384 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABCitm1Aa4WTyvBPKARI0tXk9OtRF0Hks5t8tLagaJpZM4OynGz>
.
|
Once this CL lands, I suggest that we remove the milestone. Landing the noop version of this is enough to allow the VM team to shed the underlying code. |
Agreed -- now that https://dart-review.googlesource.com/c/sdk/+/60062 is landed, the packages/ directory won't work with or without dart 2. And the deprecations have already been published. Its now clear -- as far as I can tell -- to be cleaned up at anyone's whim! |
This issue is marked closed, but nobody has ever done the work described, of actually removing the APIs. Shouldn't it be reopened until somebody does? |
These are all done a long time ago! |
Starting on the list
dart:io
Platform.packageRoot
dart:isolate
Isolate.packageRoot
Related:
pkg:package_resolver
– bug neededpkg:test
- bug neededThe text was updated successfully, but these errors were encountered: