module-naming=true enforces the naming convention on dependencies not part of a package when it is used as a dependency

[urbanjost]

Upstream Project

https://github.com/M_color

Description

If I turn on module-naming it is enforced for dependencies even
if they are in [dev-dependencies] or [test.dependencies]. Should
it be required that dependencies that should not be part of the
package when it is used as a dependency be required to follow the
naming convention?

name = "M_color"
version = "0.1.0"
license = "license"
author = "John S. Urban"
maintainer = "urbanjost@comcast.net"
copyright = "Copyright 2023, John S. Urban"

[build]
auto-executables = true
auto-tests = true
auto-examples = true
module-naming = true

[install]
library = false

[fortran]
implicit-typing = false
implicit-external = false
source-form = "free"

[dev-dependencies]
M_msg = { git = "https://github.com/urbanjost/M_msg.git" }

[[test]]
name="runTests"
source-dir="test"
main="test_suite_M_color.f90"
[test.dependencies]
M_msg = { git = "https://github.com/urbanjost/M_msg.git" }

 Warning: Dependency M_msg does not enforce module naming, but project does. 
 ERROR: Module m_help in build/dependencies/M_msg/src/M_help.f90
  does not match its package name (M_msg).
 ERROR: Module m_journal in build/dependencies/M_msg/src/M_journal.f90
  does not match its package name (M_msg).
 ERROR: Module m_verify in build/dependencies/M_msg/src/M_verify.F90
  does not match its package name (M_msg).
        Hint: Try disabling module naming in the manifest: [build] module-naming
 =false . 
<ERROR>*cmd_build* Model error: The package contains invalid module names. Naming conventions are being requested.
1

Version of fpm

>=v0.8.0

Additional Information

This places an unnecessary restriction on a package if packages it uses just for development or testing must follow the new naming conventions.

[perazz]

This is actually a good point. The consensus idea is that module naming will be enforced for all packages in a registry, (#828) and within a few releases it should be the default fpm option (#726).

So, having a mix of non-enforced modules from testing/dev packages should become less and less likely.

I personally don't see issues with allowing the user working with non-naming-enforced packages, but I'd only restrict this for the dev-dependencies. Anyways, I think some more consensus with the other @fortran-lang/admins is needed before moving forward in this direction.

[awvwgk]

In my opinion, an option like module-naming should strictly apply to the package specifying it in the manifest only. If the registry enforces module-naming = true and all dependencies being registered then there won't be an issue whether it is package local or global. However having an option in the manifest which applies globally to the whole dependency tree is something I would consider harmful as it can lead to unexpected breakage.

[perazz]

Thank you @awvwgk for your comment - I will also post my thoughts here for discussion - please note that this is just my personal thoughts, I'm happy to help implementing whatever the fpm admins converge to.

I think the reason for implementing module-naming was to avoid unforeseen module naming collisions. If my package has module-naming but its dependencies haven't, any names will be possible when linking. So it's basically like we're not enforcing any rules: anyone using my package as dependency will think that it only carries over specific names, but it's not universally true.

In short, I support that this rule should be simple and lead to a clear outcome: if my package enforces module-names, everything downstream should be enforced too, so the subset of reserved names is uniquely defined