Autoname extensions

[aplavin]

Basically everyone would follow the recommended naming scheme for extensions: extension triggered by SomePkg should be named SomePkgExt. Can this naming be done automatically to reduce repetition?

Currently, there are lots of unnecessary repetitions in the common case:

• Project.toml [extensions]
  • extension name SomePkgExt
  • package name = SomePkg
• Code
  • file name SomePkgExt.jl
  • module name module SomePkgExt

Maybe, at least some of these could be removed?
For example, instead of SomePkgExt = SomePkg allow just SomePkg in [extensions]?
And/or implicitly define module SomePkgExt in the corresponding file?

[fredrikekre]

I like that things are explicit, it also isn't more repetitive than the package itself. I think it is also nice if there is just one way to specify the extension since it is enough to learn one way.

In addition, this is something you set it up once and then don't have to bother with it again, and not something you have to type everytime you use an extension.

[aplavin]

I'm thinking about consistency, not just convenience of typing. Would be nice to have an "official" naming scheme, suggested or even enforced by Pkg.
There are already some issues with naming extensions, see eg JuliaMath/ChangesOfVariables.jl#13. Their names may seem not important at all, but turns out they are! For one, arbitrary names without a convention would prevent building sysimages.

[KristofferC]

For one, arbitrary names without a convention would prevent building sysimages

Due to some existing deficiencies. There is nothing inherently problematic about it.

[aplavin]

So, is it fine if different packages have extensions with the same name?

Due to that sysimage issue, some packages started prepending their name to the extension, leading to very long and redundant names as a result.
For instance, these lines from precompilation output:

  ✓ LogExpFunctions → LogExpFunctionsInverseFunctionsExt
  ✓ LogExpFunctions → LogExpFunctionsChainRulesCoreExt

would really be better as

  ✓ LogExpFunctions → InverseFunctionsExt
  ✓ LogExpFunctions → ChainRulesCoreExt

assuming extension names don't have to be distinct.

[aplavin]

Anyway, no matter what naming scheme is decided on, it would be nice to have it uniform and consistent across packages.