[question] Package namespace concerns

[jmpatri615]

What is your question?

I feel constrained by the conan 2.0 naming conventions and would love them to be looser. To be honest, what I really want is robust support for namespaces that doesn't completely clash with pre-existing standards.

Java namespace standards
Organization namespace
File system hierarchy of paths

I understand that the current recommendation is to use user & channel fields for namespaces, which I am currently evaluating.

Concerns that I have with this approach:

The package name is not really the package name. My first impression on interpreting the attributes name, channel, and user are that the name specifies the library, and the channel and user are present to refine upon its "flavor", such as a forked variation of the base package.

For example, the bolded items are now to be considered the packages full name, and it's not even listed consecutively.

• name/version@user/channel

• Allocating user and / or channel to be a static part of the package name (its namespace) means that these fields are not also usable for other purposes, such as specifying the organization that created the package out-of-source, or the user/team who has forked the package, and probably additional other valid uses of these fields.

• Namespace pseudo-collisions. For example, I choose a package name, lib1@org_area. Later, a new package is published to conan center as lib1. These don't collide due to my usage of user, but now this is an awfully confusing situation.

• A sorted list of packages is not sorted by namespace.

Question:

Why are the name attribute naming constraints applied to user and channel? From my very basic testing, it looks like these fields don't propagate anywhere outside of conan package identification. If this is the case, can the constraints on user and channel be relaxed because compatibility with filesystems, cmake, compilers, or other build tools isn't required?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @jmpatri615

Thanks for your question

Namespace pseudo-collisions. For example, I choose a package name, lib1@org_area. Later, a new package is published to conan center as lib1. These don't collide due to my usage of user, but now this is an awfully confusing situation.

Yes, packages do collide only by package name. zlib/1.3 and zlib/1.3@user/channel cannot coexist in the same visibility scope (they can if they are isolated via visible=False trait, but that is an unusual use case). They will raise a "Conflict error" in the same way that zlib/1.3 and zlib/1.4 would conflict.

Why are the name attribute naming constraints applied to user and channel? From my very basic testing, it looks like these fields don't propagate anywhere outside of conan package identification. If this is the case, can the constraints on user and channel be relaxed because compatibility with filesystems, cmake, compilers, or other build tools isn't required?

I am afraid I don't understand the question. What constraints do you refer to? These fields are useful for example to apply some patterns like you can do something like */*@myorg/* to decide that your packages from your org follow certain logic, and packages from ConanCenter (without user/channel dont). Also servers like Artifactory structure the package views by user, which can be convenient for server navigation and maintenance .

I am not sure how the user and channel are related to compatibility with filesystems, cmake, compilers or anything like that. It is just like a qualifier to the packages names, that can be used or not. You could call your packages myorg_mypkg/version too, without user/channel, it is just a naming thing. Not related to build systems, file systems or CMake at all.

Thanks for your feedback!

[jmpatri615]

Thanks for the reply.

Why are the name attribute naming constraints applied to user and channel? From my very basic testing, it looks like these fields don't propagate anywhere outside of conan package identification. If this is the case, can the constraints on user and channel be relaxed because compatibility with filesystems, cmake, compilers, or other build tools isn't required?

I am afraid I don't understand the question. What constraints do you refer to? These fields are useful for example to apply some patterns like you can do something like */*@myorg/* to decide that your packages from your org follow certain logic, and packages from ConanCenter (without user/channel dont). Also servers like Artifactory structure the package views by user, which can be convenient for server navigation and maintenance .

I am not sure how the user and channel are related to compatibility with filesystems, cmake, compilers or anything like that. It is just like a qualifier to the packages names, that can be used or not. You could call your packages myorg_mypkg/version too, without user/channel, it is just a naming thing. Not related to build systems, file systems or CMake at all.

conan-io/docs#3329 (comment)

This reply documents how valid conan names continue to generate warnings, and that is desired. I'm asking why special characters in the user and version attribute fields need to have the same constraints applied to them as the name field?

The specific comment I'm linking to mentions

many integrations, build system, generators can struggle with filenames, variables, etc that contain these special characters that will appear

Are the user and channel attribute information that gets passed along to cmake, a compiler, or as part of a filename or path on the filesystem? If not, then perhaps having unique validation rules for these fields would allow for more special characters to be used in these fields, such as the dot.

[memsharded]

I understand now, thanks for the clarification.

The user and channel fields can and are actually used in a variety of places:

• In filesystem it was ubiquitous with Conan 1, and in Conan 2, user and channel can appear in folder names in cases like when using deployers
• They are used in server side in DB fields that can have character constraints
• They are used in server side in filesystem paths (check conan_server paths for example
• They are used a lot in client side pattern matching, regex and many other user automation, that special characters will be quite problematic
• They are used in server side automation, like that above commented Artifactory exclude patterns
• In SBOMs, like cyclonedx or spdx, and other manifests formats, in which special characters can be problematic, need extra escaping, etc.
• In many Conan internal logic, there are rules for parsing files that can contain something like pkg/version@user/channel:somekey+=(path)somevalue. Allowing special chars in user/channel like :+=() would make the parsing more complicated and most likely slower.

Besides the functional constraints, there are other UX reasons, like for example, these might be identifiers that developers have to type sometimes, like many Conan command takes full references including user and channel. Special characters can be inconvenient, require extra terminal quoting (note conan install --requires=pkg/version@user/channel is very unlikely to need extra quoting).

I am a bit surprised that not allowing special characters in user/channel is a limitation somehow. Up to my knowledge many other package technologies won't allow special characters in package identifiers either. The channel is not recommended anymore for any dynamic/pipeline quality stages and should be either drop or immutable, and the user name should be something simple like myteam or myorg. We don't think that allowing there special chars would have any substantial benefits, but it would certainly have a lot of risks and disadvantages.