[native_assets_cli] Package name

[dcharkes]

trafficstars

After we add support for hook/link.dart we'll have a LinkConfig and LinkOutput that will share some types with the BuildConfig and BuildOutput.

And after adding DataAssets we'll have more assets than CCodeAssets/NativeCodeAssets.

So, the question is what this package should be renamed to:

• build_hook / build_script (https://github.com/dart-lang/native/issues/154#issue-1931168915). But that wouldn't fit well with also having the hook/link.dart protocol.
• build_protocol, build_config_cli, build_hook_cli, build_hook_protocol (https://github.com/dart-lang/native/pull/946#discussion_r1502759157) Ditto, it wouldn't fit well with also having the hook/link.dart protocol.

Original tracking issue:

• https://github.com/dart-lang/native/issues/154

cc @mosuem @mkustermann

[mkustermann]

Would it make sense to go away from "native" and from "assets" and instead use package:dart_build / package:dbuild / ...?

[dcharkes]

dart_build still doesn't cover a link hook.

I think I'd prefer build_hook over dart_build, it's more clearly connected the "hook"s (https://github.com/dart-lang/sdk/issues/54334).

What's a good name for the "build hook" and "link hook"? (I think they should live in the same package, as they will have many shared classes.)

[dcharkes]

Notes from discussion with @mosuem

• package:build_hook/build.dart
• package:build_hook/link.dart contains LinkConfig and LinkOutput

(package:compilation_hooks/build.dart was rejected because compilation_hooks is hard to connect with build.dart and link.dart)

[mosuem]

Throwing some nice not-as-technical names in the ring: package:weave or package:forge (my personal favorite).

[dcharkes]

From discussion with @mkustermann @HosseinYousefi @mosuem:

• package:hook/build.dart and package:hook/link.dart.

Which might conflict with package:hooks (11 years old, not update in 10 years). Maybe that package can be deprecated.

[HosseinYousefi]

I like package:hook.

@influx6 Would you mind transferring the ownership of your package:hooks to us? I don't want any confusion with package:hook.

cc/ @jonasfj

[influx6]

@HosseinYousefi I need an email to use to transfer to

[influx6]

I sent the invite to [email protected]

[HosseinYousefi]

I sent the invite to [redacted].

We can move this conversation to email. I think @mosuem had already contacted you, let's talk about the correct email there.

[dcharkes]

I sent the invite to [email protected]

Thanks @influx6! I have accepted the invite. 👍

@jonasfj Is marking the package:hooks discontinued enough for us to be able to upload a new package:hook?

[dcharkes]

@influx6 You might want to update the readme on the repo that it's discontinued and archive the GitHub repo.

Given that the SDK constraint is <2.0.0, I presume at this point we have 0 users. 😄 (The current Dart SDK releases can only run 2.12 and higher.) So we might even retract the whole package to avoid users making a typo in their pubspec and getting an error that they need Dart 1 instead of package:hooks not existing.

[jonasfj]

@jonasfj Is marking the package:hooks discontinued enough for us to be able to upload a new package:hook?

No, it's not.

pub.dev will generally, not allow publication of hook if hooks exist (and vice versa). This just some arbitrary rules we have in place to disallow similar package names. Exceptions to the rules on similar package names can be granted on a case by case basis.

The rules on similar package names are there to prevent typo squatting attacks. But if we can see that it's not an attack, we can make exemptions on a case by case basis.

In a case like this, where:

• The owner of hooks consent to the creation of hook; AND;
• The owners of both packages are aware that these similarly named packages exist; AND;
• All parties trust each other not to attempt a typo squatting attack; AND;
• All parties are aware of the potential confusion (and minor pain) that similarly named packages can bring. In such cases, I think an exemption to allow the creation of package:hook is fair :D

Formally, this is done by adding hook to reserved package name list: https://github.com/dart-lang/pub-dev/blob/b786b24ebea84705d0ba6c13b11a9e6f8d72a0c2/app/lib/package/overrides.dart#L9

Once deployed a Googler can create the package, and transfer it the people who requested it be created. In this case, that'd be you, so really you could just create it.

[dcharkes]

If we're going for package:hook (singular), then it's slightly weird to go for package:code_assets (plural) and package:data_assets (plural).

Because we will start name spacing with package name (https://github.com/dart-lang/native/issues/2132), we need to decide on those package names now.

Should we consider package:data_asset and package:code_asset instead? cc @HosseinYousefi @mosuem @mkustermann? (Let the bike shedding begin!)

[mosuem]

Should we consider package:data_asset and package:code_asset instead?

Yes (let the bike shedding stop 😉 ). I am also fine with package:hooks though. We should just be kind of consistent.

[dcharkes]

The majority of packages related to icon, font, asset have plural names on pub.dev, so I'm leaning towards plural for data_assets and code_assets.

For the hook/ directory we've settled in singular as per Dart conventions: https://dart.dev/tools/pub/package-layout. (Flutter diverges from these conventions with the assets/ directory: https://dart.dev/tools/pub/package-layout#public-assets.)

So should package:hooks follow the package name conventions then or stay close to the directory name as in package:hook. (package:hooks will ensure users will never land on the 11 year old package:hooks, but also means that history is forever visible.)