-
Notifications
You must be signed in to change notification settings - Fork 362
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
Migration to null safety #501
Comments
Related PR #496 Not sure when it will be published |
@mit-mit when we should expect the null safety version of this package on pub.dev? Since I am looking to upgrade my package web_scraper to null safety but that depends on the |
I am also blocked on finishing a migration of a package. |
Any update on this? It is the highest blocking package according to https://github.com/dart-lang/sdk/wiki/Null-safety-migration-status |
It seems as if the master already contains a null safe implementation. Any reason this hasn't been published yet? |
Quick update on this on Twitter: https://twitter.com/kevmoo/status/1340382649366429696?s=20 Basically, its being tested with internal Google code before they publish. |
@kevmoo: any updates? |
@natebosch is driving things here AFAIK |
We are currently evaluating and preparing for a couple breaking changes which needs to happen before the null safety migration can be published. Those are:
#424 is looking like it may need more design work before we can move forward with it, so it's plausible that we'll only block on adding a All of these are breaking changes for only a very small subset of consuming packages. Blocking the publish on these changes is mainly a function to reduce churn from multiple major version bumps, and to avoid blocking those changes until after the null safety release goes stable. We are aware of the urgency for this migration and it's a high priority. |
@natebosch As a suggestion, why not plan out the version numbers in advance, and "reserve" a major version number for the breaking release when it's ready, but publish a null safety prelease now using a major version above that? I believe this is the approach taken by rxdart who jumped from rxdart 0.24.1 up to rxdart 0.26.0-nullsafety.0 while reserving 0.25.0 for a stable release of planned breaking changes. |
Publishing with an unnecessarily high version number means that a breakage would flip-flop and make it impossible to use a range constraint. You could be compatible with |
Only temporarily until
|
One other point concerning the various breaking APIs being introduced is that you could use the experimental annotation which would allow later changes without a version bump, "during" this transition period. That will buy you some time to refine things without blocking others. I know it would be ideal to wait for the perfect API before releasing, but it is worth standing back and noticing that many package developers have come to the collective conclusion that they had better get any important breaking API changes in before the null-safety migration otherwise it could take a really long time to wait for the next major version bump where we can finally make those changes. If everyone takes the same attitude of trying to perfect their API before the transition, this is going to be a very painful and tiring migration. That is to say, even if the perfect It is also worth considering that those who migrated their packages earlier may have it worse off because now the development of their package may be blocked until everyone else has caught up and the null safety branch can actually be used. |
I don't support create a 2.0.0-nullsafe version for when there are breaking changes in 1.0.0. This would also mean that if the breaking changes of 1.0.0 are also applied in 2.0.0 this breaks 2.0.0 and you would actually have to publish the nullsafe version as 3.0.0, as otherwise However, I do wonder if we as community developers help speed up the development of these tickets, or that we are just waiting for internal discussions and development is not really the problem here. If I'm correct the only one left is #424, it looks like a decision on how to go forward is made, but not everybody agrees on it yet. I'm happy to help with anything though. |
FYI, http is blocking build_runner which is blocking virtually any serious migration to null safety from most projects. It's vital that this gets out at least in a pre-release form as soon as possible. |
We are aware that |
Your patience is greatly appreciated here. @natebosch and others are working VERY hard to make sure |
FYI, the image_picker plugin's NNBD migration is also blocked by this :) https://github.com/flutter/plugins/blob/master/packages/image_picker/image_picker_platform_interface/pubspec.yaml |
@natebosch If you add build_runner to dev_dependancies then it blocks everything else from being updated that depends on it (json_serializer, injectable, freezed etc.) The build_runner team has committed to expanding the compatibility specs in their yaml to allow your null safety version when it comes out and all other packages thus allowing you to upgrade the entirety of the rest of your project before build_runner is updated. Hence why I made the comment. There is a specific plan to make this work but it depends on http being updated to null safety or doing the same as build_runner. Here's their issue: dart-lang/build#2920 (comment) |
It is expected that during ongoing migration work you may need to use
I'm on the build_runner team. We will be publishing versions with expanded constraints on a best-effort basis to make things easier as packages are published. That dependency will not be migrated soon, and it does not block migrations. The null safe output from generators like To reiterate. No migration work is blocked by this package being unpublished. What is blocked is publishing other migrated packages that depend on this. I am fully aware of the pain caused by dependency overrides and publishing this package remains a high priority. The urgency is based on being able to publish other packages, not on being able to use the migrate tool and make the code changes which is already possible. To make progress on a migration put the following in your pubspec: dependency_overrides:
http:
git: git://github.com/dart-lang/http.git You can follow this issue to know when you will be able to remove the override and be able to publish. As other breaking changes are made within this package, you may have to make small adjustments to your usage. I don't expect any further breaking changes that impact the majority of consumers between now and the null safety release. There may still be minor breaking changes that effect classes which |
Published https://pub.dev/packages/http/versions/0.13.0-nullsafety.0 We hit some more uncertainty around implementing timeouts so we're gonna hold off on that until we can work on a design alongside general request aborting. |
Is there already a plan to migrate this library to null safety?
The text was updated successfully, but these errors were encountered: