Pub: 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.

[mit-mit]

cc @kevmoo @jonasfj @lrhn @leafpetersen @munificent any concerns with this? I guess it's potentially 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.