Stop producing .packages

[mit-mit]

We added logic to produce the new packages file: .dart_tool/package_config.json, however we now generate both that and .packages. I think we should stop generating .packages, so that there is a single master, and less room for confusion.

Known dependants of the .packages file that will need to get fixed first:

• dart.dev docs: Migrate documentation from .packages to .dart_tools/package_config.json site-www#3422
• IntelliJ plugin: The .packages file is obsolete and should not be used flutter/flutter-intellij#5614

[mit-mit]

cc @kevmoo @jonasfj @lrhn @leafpetersen @munificent any concerns with this? I guess it is a breaking change and should be announced?

[mit-mit]

Even further, I think we should consider having pub delete any existing .packages when it creates the new config file.

[lrhn]

There is a number of (third-party?) tools which read .packages. That's the ones we broke them when we tried added the version information to the .packages file itself.
We chose to make a different configuration file in order to not break these tools.
Removing .packages will likely break those tools again, so we need to force them all to migrate before that's a real possibility - breaking them was considered too problematic once already, and I don't see what should have changed since then.
I'm willing to bet that none of them have migrated to package_config.json yet.

[jakemac53]

Ya, the original plan was to wait a (long) while before deleting this file, possibly even until Dart 3.0. The value of removing it likely doesn't justify the breaking change at this time given all the other churn that is happening due to NNBD and language versioning.

We could add a pointer to the new file in the comment at the top of the file?

[jonasfj]

possibly even until Dart 3.0

Seems reasonable to me... Or at-least we should wait until users have migrated from package_config 1.x to 2.x, given that we're in that process and haven't done it yet, I think it's best to wait a bit.

[jakemac53]

Part of the problem is the old format was so easy to parse there was little reason to even depend on package_config in the first place, so tools often did not and parsed it on their own. So unfortunately even if the world migrates to package_config 2.x which has no .packages support we will still likely have usage of it.

[lrhn]

We will move away from creating .packages, and I am hopeful we can do it within a few quarters. Those tools need to be updated. I just don't think we can break them without some migration time, by removing .packages immediately.

(It would be interesting to add a flag that makes Pub generate the .packages files, one which defaults to on for now, would flip to being off in, say, one quarter, and then be removed/disabled in two quarters. Then we could run tests in google3 with the flag off and see which code still needs to be migrated. @jonasfj, WDYT?)

[natebosch]

Then we could run tests in google3 with the flag off and see which code still needs to be migrated.

pub is not used internally. Our concerns are around tools in the external ecosystem, and it will be more challenging to have confidence we've caught everything.

[leafpetersen]

cc @devoncarew who I think was familiar with some of the external tooling that uses .packages (something around Intellij perhaps?).

[devoncarew]

Fuchsia I believe also reads the .packages file.

It would be good to track the tools that need to migrate, and slowly change them over, but we'll want that changeover to be a fair ways out.

[devoncarew]

run tests in google3 with the flag off and see which code still needs to be migrated

And, CIs won't provide many signals for which tools will break.

[mit-mit]

I moved this to the SDK tracker as it's such a cross-cutting issue.

[rakudrama]

In my personal workflow on small code snippets (often copy/paste from bug reports) I use

dart/sdk$ sdk/bin/dart --packages=.packages  /some/path/foo.dart
dart/sdk$ sdk/bin/dart2js_developer --packages=.packages  /some/path/foo.dart

What would this look like if .packages was removed?
I have over 1200 of these small programs, so creating some kind of project for each one would cumulatively have been quite a burden.

[mit-mit]

Can't you just pass a package_config.json file instead?

dart/sdk$ sdk/bin/dart --packages=package_config.json /some/path/foo.dart
dart/sdk$ sdk/bin/dart2js_developer --packages=package_config.json  /some/path/foo.dart

Yes, we'd have to replace our current .packages file with a package_config.json file, but that is an SDK specific issue.

[natebosch]

Yes, we'd have to replace our current .packages file with a package_config.json file, but that is an SDK specific issue.

@rakudrama - this issue refers to the .packages file created by dart pub get in packages. I think you're referring to doing development directly in the SDK repo. That .packages file removal is tracked at #48275

We already have a replacement file it the SDK repo, you can change --packages=.packages to --packages=.dart_tool/package_config.json. This should work today.

[sigmundch]

An issue we discovered today that is worth tracking before we stop generating .packages files:

• Remove CFE/analyzer/compiler/VM support for .packages file #48939

[mit-mit]

PR for this: dart-lang/pub#3413

I'll move the VM issue discussed in #47431 (comment) to #48272

[mit-mit]

Roll is https://dart-review.googlesource.com/c/sdk/+/244621

[sigurdm]

Roll is https://dart-review.googlesource.com/c/sdk/+/244621

Actual roll is: https://dart-review.googlesource.com/c/sdk/+/244623