[bug] Name containing '-' issues a discouraged warning

[offa]

Packages coning a - in the name cause a warning:

WARN: Name containing special chars is discouraged 'warning-repro'

- is a valid character according to docs.

Environment details

• Operating System+version: Linux
• Compiler+version: GCC 12
• Conan version: 2.0.1
• Python version: 3.10

Steps to reproduce

1. Create a conanfile.py with a name attribute containing - (eg. name = "warning-repro")
2. Do conan create

conan new cmake_lib -d name=warning-repro -d version=0.1
conan create .

Logs

conan create .

======== Exporting recipe to the cache ========
WARN: Name containing special chars is discouraged 'warning-repro'
[…]

[memsharded]

Hi @offa

Thanks for your report.

This is the reason why - doesn't raise an error, because it is possible to use it.
However, it is so problematic for many build systems and tools that it is warning, to discourage its use. It is very recommended not to use such names, but avoid the - completely. It wasn't fully forbidden to allow an easier transition and upgrade to 2.0, but the warning is legit, this wouldn't be a bug.

[offa]

Thanks, that's fine to me and I'm replace it with _.

It should be mention in the docs though, especially if it may cause trouble.

[memsharded]

It should be mention in the docs though, especially if it may cause trouble.

Definitely. But most people won't read the docs, specially if there is not an issue. So the warning in the output is the thing that works way better than the docs.
Lets move this to the docs repo for improvement, thanks for the feedback!

[offa]

Perfect! :-)

[memsharded]

We are finally removing this warning in conan-io/conan#15920 for 2.3, there are too many packages in ConanCenter with "-", this would be too much to migrate.

[jmpatri615]

@memsharded - I'd like to advocate for adding the rationale to the docs, as I do read the docs and find the discrepancy between valid package names and "best-practice" package names to be frustrating. As I migrate my org towards conan I'd prefer to align with best practices but have accidentally fallen into the discouraged package names category.

I found my way to the rationale by:

• searching github for "special chars"
• Running git-blame on conans/models/recipe_ref.py
• Reading through the related issues and their PR's, [bug] WARN: Name containing special chars is discouraged 'hello-world' #3329 and [bug] Name containing '-' issues a discouraged warning #3086.

Proper docs would have been helpful.

Regarding my use of special characters in package names, my org has existing package namespaces that I'd like to leverage, basically org.area.name, is there an alternate/more preferred method of managing package namespaces?

[memsharded]

I'd like to advocate for adding the rationale to the docs, as I do read the docs and find the discrepancy between valid package names and "best-practice" package names to be frustrating. As I migrate my org towards conan I'd prefer to align with best practices but have accidentally fallen into the discouraged package names category.

Some part of the rationale is historic reasons, things were allowed in the past and cannot really be forbidded/enforced, so warnings is the only effective way to move away from these for future Conan versions. We have found that docs are like an order of magnitude less read than those warnings, so this is why typically the warnings precede proper docs rationale.

Regarding my use of special characters in package names, my org has existing package namespaces that I'd like to leverage, basically org.area.name, is there an alternate/more preferred method of managing package namespaces?

Mostly using underscore _ is kind of universally replacement for special chars in programming, so this is very widely used.
Other possibilities would be:

• name/version@org_area (without channel)
• Using hyphen/minus - is allowed and not discouraged so far, as it seems it is less problematic in filesystems and build systems.

[jmpatri615]

Thanks for your replies on this and the other related thread.

At this time, I think the plan is to put our namespace into the package name field, using underscores. This will provide our teams with the confidence that they are not duplicating a package name, which could cause frustrating debug sessions in the future, and enable usage of public packages that do have the same shortname.

This will make package names less readable since our areas and names already contain underscores and hyphens.

[memsharded]

At this time, I think the plan is to put our namespace into the package name field, using underscores. This will provide our teams with the confidence that they are not duplicating a package name, which could cause frustrating debug sessions in the future, and enable usage of public packages that do have the same shortname.

Sounds reasonable, thanks for the feedback.

This will make package names less readable since our areas and names already contain underscores and hyphens.

Yes, we understand that tradeoff, similar to the one in other languages and systems, as java. On the other hand we know that it reduces other issues later down the road, when some application that uses some tool or build system crashes when it tries to use packages with special characters in the names, because they don't manage those correctly, and at that time, the pain is much much higher, because it is not simple to rename the package anymore as it is already used by others.