[breaking change] discontinue .packages file #48272
Assignees
Labels
area-meta
Cross-cutting, high-level issues (for tracking many other implementation issues, ...).
area-sdk
Use area-sdk for general purpose SDK issues (packaging, distribution, …).
breaking-change-request
This tracks requests for feedback on breaking changes
Milestone
Comments
mit-mit
added
the
breaking-change-request
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
kevmoo
added
area-meta
|
Breaking change was announced: |
|
I believe this will impact a number of packages. cc @natebosch Off the top of my head, we rely on this file in |
|
I have no objection in principle but I would not be surprised if this broke things unexpectedly (e.g. we probably have tests that depend on |
copybara-service bot
pushed a commit
that referenced
this issue
Mar 4, 2022
…the analysis server spec_input.html Bug: #48272 Change-Id: Ica02829fbf9309327210e67d059d4606bb58b528 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/235282 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Jaime Wren <[email protected]>
I would have thought we'd migrated to |
This was referenced Mar 7, 2022
Filed dart-lang/webdev#1526; @annagrin are you the right assignee for that?
Filed dart-lang/tools#483; @liamappelbe are you the right assignee for that? |
|
Yep, I can take a look |
|
IJ YouTrack issue is now marked as Fixed, with the PR JetBrains/intellij-plugins#862, landed on the |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as outdated.
This comment was marked as outdated.
vsmenon
modified the milestones:
February Release (Dart 2.17 beta 2),
March Release (Dart 2.17 beta 3 + stable candidate)
|
@mit-mit - are we still targeting this for the upcoming beta / stable? Or kicking to the next one? |
mit-mit
removed this from the March Release (Dart 2.17 beta 3 + stable candidate) milestone
|
No, we're punting this to 2.18, and will try to make the change very early in that release cycle rather than very late in the current one. |
cbracken
added a commit
to cbracken/flutter
that referenced
this issue
May 14, 2022
This rolls depdendencies to latest using flutter update-packages --force-upgrade This change includes three code changes: * Removes charcode from the dependencies allowlist since it no longer appears in the transitive closure of dependencies of the flutter, flutter_test, flutter_driver, flutter_localizations, and integration_test packages. * Uses Resolver.create instead of the deprecated Resolver constructor. The default Resolver constructor has been deprecated in favour of the static Resolver.create() factory function, which unfortunately happens to be async. Propagated the async-ness up the chain. * Eliminates the use of the deprecated packagesPath parameter to HitMap.parseJson. This parameter was deprecated and replaced with packagePath in dart-archive/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This is a pre-update prior to updating flutter_template_images in flutter#103739 Issue: flutter#103371 Issue: flutter#103775
cbracken
added a commit
to flutter/flutter
that referenced
this issue
May 14, 2022
Roll dependendencies This rolls depdendencies to latest using flutter update-packages --force-upgrade This change includes three code changes: * Removes charcode from the dependencies allowlist since it no longer appears in the transitive closure of dependencies of the flutter, flutter_test, flutter_driver, flutter_localizations, and integration_test packages. * Uses Resolver.create instead of the deprecated Resolver constructor. The default Resolver constructor has been deprecated in favour of the static Resolver.create() factory function, which unfortunately happens to be async. Propagated the async-ness up the chain. This change was partially reverted and the deprecation ignored in this patch until package:coverage can be rolled internally at Google. * Eliminates the use of the deprecated packagesPath parameter to HitMap.parseJson. This parameter was deprecated and replaced with packagePath in dart-archive/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This change was partially reverted and the deprecation ignored in this patch until package:coverage can be rolled internally at Google. This is a pre-update prior to updating flutter_template_images in #103739 Issue: #103371 Issue: #103775 Issue: #103830 When re-applying the partially-reverted changes to code coverage, we'll need to patch host_entrypoint.dart internally to await the Future that we'll be returning rather than a non-async value.
This was referenced May 18, 2022
github-actions bot
pushed a commit
to gnoliyil/fuchsia
that referenced
this issue
May 20, 2022
dart-lang/sdk#48272 introduced a breaking change which removed the creation of the .packages file which is breaking in an upcoming flutter roll. The tool has been creating the .dart_tool/packages_config.json file so we can soft transition before we roll. Change-Id: I306653e9392d4f83164a4c608a82cb09cedb8b2a Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/681819 Reviewed-by: Theodore Siu <[email protected]> Commit-Queue: Chase Latta <[email protected]>
othorin
added a commit
to othorin/graphql-flutter
that referenced
this issue
May 21, 2022
8 tasks
cbracken
added a commit
to flutter/flutter
that referenced
this issue
May 31, 2022
In #103771, we rolled dependencies in Flutter, which triggered an update of package:coverage to v1.3.1. The new version includes dart-archive/coverage#370 in which two deprecations landed: * The `Resolver` default constructor was deprecated and replaced with the `Resolver.create` static factory method, which unfortunately happens to be async. * The `packagesPath` parameter to `HitMap.parseJson`, which takes the path to the `.packages` file of the package for which coverage is to be collected, was deprecated. This parameter was replaced with `packagePath` in dart-archive/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This migrates off the deprecated `packagesPath` parameter to the replacement `packagePath` paramter. Issue: #103830
github-actions bot
pushed a commit
to gnoliyil/fuchsia
that referenced
this issue
Jun 15, 2022
.dart_tool/package_config.json as opposed to .packages. .packages is being deprecated and will no longer be generated by the `dart pub get` command. https: //github.com/dart-lang/sdk/issues/48272 Change-Id: Ib50ab3680216dadafa7f7263223289061f659248 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/685904 Reviewed-by: Alexander Biggs <[email protected]> Commit-Queue: Naud Ghebre <[email protected]>
|
Closing as completed. The only remaining future work is to remove the temporary flag in pub; dart-lang/pub#3496 tracks this. |
camsim99
pushed a commit
to camsim99/flutter
that referenced
this issue
Aug 10, 2022
In flutter#103771, we rolled dependencies in Flutter, which triggered an update of package:coverage to v1.3.1. The new version includes dart-archive/coverage#370 in which two deprecations landed: * The `Resolver` default constructor was deprecated and replaced with the `Resolver.create` static factory method, which unfortunately happens to be async. * The `packagesPath` parameter to `HitMap.parseJson`, which takes the path to the `.packages` file of the package for which coverage is to be collected, was deprecated. This parameter was replaced with `packagePath` in dart-archive/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This migrates off the deprecated `packagesPath` parameter to the replacement `packagePath` paramter. Issue: flutter#103830
albertms10
added a commit
to albertms10/music_notes
that referenced
this issue
Apr 5, 2023
albertms10
added a commit
to albertms10/music_notes
that referenced
this issue
Apr 5, 2023
* chore(vscode): include `settings.json` * chore(pubspec): bump versions as of Dart SDK 2.19 * feat(analysis): add `dart_code_metrics` and refactor code * ci(analysis): bump versions, run DCM and strengthen security * ci(analysis): remove `--no-pub` option from `dart analyze` Only available in `flutter analyze` * ci(analysis): remove discontinued `.packages` file reference See dart-lang/sdk#48272
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Intended change in behaviour
When the commands
dart pub getorflutter pub getare executed, pub resolves all dependencies, and downloads those dependencies to the local pub cache. It furthermore creates a mapping from each used package to their location on the local file system. Today this mapping is stored in two files:.dart_tool/package_config.json.packages(legacy, as of Dart 2.8.0)The former of these is the file that the current SDKs rely on. The latter has until now been generated for backwards compatibility with older Dart SDKs. After the present breaking change is made, we'll change
pub getto only generate the former (.dart_tool/package_config.json), and the Dart SDK will no longer be able to read the.packagesfile.Rationale for making the change
The
.packagesfile is left-over from older Dart SDKs and is not fully compatible with Dart 2.x SDKs (it, for example, doesn’t support language versioning). We're removing the generation of.packagesto prevent having extraneous files in the file system, and to prevent corner-case bugs that may occur if both files are around, but in an inconsistent state.Expected impact of this change.
Regular apps and packages that are written using Dart 2.x will not be impacted, as they rely on
.dart_tool/package_config.json.If you already have a
.packagesfile, you can delete it. After upgrading your Dart SDK it will no longer be generated, and pub will delete it when pub get runs.Developer tools that need to look up the packages used by a project, and their locations on the file system, will no longer be able to rely on the
.packagesfile. Such tools should be upgraded to rely on the content of thepackage_config.jsonfile. Rather than reading this file directly, we strongly recommend using the API for consuming it available inpackage:package_config.If you are passing a
.packagesfile to thedartcommand (dart --packages=.packages) you'll need to pass the package config instead (dart --packages=.dart_tool/package_config.json).Steps for mitigating the change
If you for some reason depend on this legacy file, you will for one stable release be able to generate it by passing the flag
--legacy-packages-filetodart pub get/flutter pub get. After one stable release, this flag will be removed, and all support for generating the legacy file be removed. Note however this this is only being offered for external tools that may depend on the.packagesfile; all tools offered by the Dart team will no longer support this.packagesfile.Timeline
The change to no longer generate
.packages, and to remove support for reading that file in tools offered by the Dart team / the Dart SDK, will be made in a dev-channel release of Dart 2.18.The
--legacy-packages-fileflag -- which offers a temporary solution for retaining the generation of.packagesfor other legacy tools -- will be removed one release later in a dev-channel release of Dart 2.19.Related issues
In the Dart 2.18 stable release:
.packages file: Stop producing .packages #47431, Stop generating.packagespub#2756.packages.packages: Remove CFE/analyzer/compiler/VM support for.packagesfile #48939.packagein mainsdkrepo: Remove.packagesfrom the Dart SDK repo #48275.packagesto detect if dependencies needs to be fetched Dart-Code/Dart-Code#3813package_configdart-archive/dart-services#834In the following Dart 2.19 stable release:
--legacy-packages-fileflag entirely: Discontinue--legacy-packages-fileflag pub#3496The text was updated successfully, but these errors were encountered: