Cre8or_Generic_Image_Handling (1.0.0)

[Cre8or]

This PR adds my Generic_Image_Handling library (and corresponding example project) crates.

If anything seems odd or needs fixing please do let me know, as this is my first Alire submission.

Personally I'm not too keen on appending my name to every package/library name, but from what I understand there is no better way of future-proofing against naming conflicts (unless I'm missing something super obvious).

[mosteo]

Personally I'm not too keen on appending my name to every package/library name, but from what I understand there is no better way of future-proofing against naming conflicts (unless I'm missing something super obvious).

This is correct, there's no namespacing at the moment.

[Fabien-Chouteau]

@Cre8or what naming conflicts do you expect? Once you have the crate in the community index no one else can use the same name.

[Cre8or]

@Cre8or what naming conflicts do you expect? Once you have the crate in the community index no one else can use the same name.

My concern was more with regards to larger projects. If I with two libraries in my project, and as an example each of them has a package Logging in it, the compilation will fail (due to the two packages sharing the same name). Now, this might seem far-fetched but as the community index grows, the likelihood of this issue arising grows too.

I couldn't find much information on how to best avoid this, so I did some experimenting and landed on two possible solutions:

1. create all my units under a shared root package named after me (e.g. Cre8or - similar to namespaces in Java)
2. prefix all my units with my name (the solution I ended up going for)

Option 1 would have been my preferred choice, but it results in the exact same problem as described above, because I'd have a package Cre8or in every library I make, which would again lead to naming conflicts.

So I'm open for suggestions. Is my approach wrong? Am I looking at it the wrong way? Did I miss something obvious? Or is it all just not as much of a concern as I think it is? I still don't have enough experience to judge that, having used Ada for mostly personal-use or professional projects (without any external dependencies).

[BrentSeidel]

I couldn't find much information on how to best avoid this, so I did some experimenting and landed on two possible solutions:

1. create all my units under a shared root package named after me (e.g. Cre8or - similar to namespaces in Java)
2. prefix all my units with my name (the solution I ended up going for)

Option 1 would have been my preferred choice, but it results in the exact same problem as described above, because I'd have a package Cre8or in every library I make, which would again lead to naming conflicts.

So I'm open for suggestions. Is my approach wrong? Am I looking at it the wrong way? Did I miss something obvious? Or is it all just not as much of a concern as I think it is? I still don't have enough experience to judge that, having used Ada for mostly personal-use or professional projects (without any external dependencies).

My approach was similar to your option 1. I have a root package with my initials (bbs). All of my other libraries are sub packages of that root package. However I put it in a separate crate so that all of my library crates depend on it. It also allows me to define some common types and such there and not have to keep repeating myself.

[Cre8or]

Ah! I was worried that submitting a library package whose main purpose is to reserve a namespace could come across negatively (if I remember correctly, name squatting is an issue over at the Rust community index).

If this is an approved approach, I'll consider making the switch too.

[BrentSeidel]

I'm not sure how negatively it's viewed. I just tried it and it was accepted. However mine wasn't just an empty package. It defined a number of types that are commonly used in my other packages and a number of unit conversions. You can take a look at the "bbs" crate and other "bbs_*" crates to see how I organized things.

[Fabien-Chouteau]

If this is an approved approach, I'll consider making the switch too.

I personally think this is the wrong approach. Dependencies are not completely free and you should avoid making a crate for just 2 lines of code.

We recommend using the same name for the crate and the root package. Crate names already live in a namespace. If we all follow this principle, the conflict will be detected as soon as one tries to publish a crate, and therefore, the name can be changed in reaction to this.

[Cre8or]

I personally think this is the wrong approach. Dependencies are not completely free and you should avoid making a crate for just 2 lines of code.

Understood. As I don't currently have a real need for a root package that is shared across all of my projects, I'm fine with continuing with my current approach. Still a shame that there isn't a way to ship a root package with every library and somehow have the build toolchain only pick one (to avoid compilation errors), but I imagine that's outside of Alire's scope.