Suggestion for DUB users: The vanity package

[WebFreak001]

On Tuesday, 19 October 2021 at 04:03:38 UTC, Mathias LANG wrote:
> I was looking at a few packages recently, and noticed a 
> bothering trend: Single-module libraries ending up at the top 
> level.
>
> Why is it bothering ? Well, here's a little puzzle: Does the 
> following code compile?
> ```D
> import std.stdio;
>
> void main ()
> {
>     writeln(foo.stringof);
> }
> ```
>
> The answer is "maybe". In most case, it will not. However, if 
> the file this resides in is named `foo.d`, it will compile. 
> Because the module name accounts for an identifier that can be 
> addressed in the scope of the module (and other modules that 
> import it).
>
> Now imagine what would happen if `core.atomic` or `core.time` 
> were top-level modules ? Conflicts, conflicts everywhere. It 
> only gets worse with imports, as `import atomic;` would insert 
> the `atomic` name into the current scope, which would then 
> shadow any symbol named `atomic` in any import (there used to 
> be an evil hack in the compiler to make this special case work 
> - it is gone since a few releases).
>
> So what's the solution ? Well we could go with the Java-esque 
> `com.foo`, but that'd be a bit ridiculous. Instead, for a few 
> years now, I have started a habit of using the "vanity 
> package", a top-level package with my username, for simple 
> libraries I publish:
> - 
> https://github.com/Geod24/bitblob/blob/v2.2.0/source/geod24/bitblob.d#L16
> - 
> https://github.com/Geod24/localrest/blob/ddfa8cd3bc2f48e1dfc5edd803b990e5aaa69044/source/geod24/LocalRest.d#L102
> - 
> https://github.com/Geod24/minivariant/blob/d20b240d45289a857b4c0d6e7f842a92b3d4a19e/source/geod24/variant.d#L30
>
> It "just works", is pretty simple to remember, easily 
> extendable, and you can be pretty sure no user of your library 
> will run into conflicts. I encourage anyone considering 
> publishing a package to do the same.

I like this idea. We should put this on the dub documentation to 
make more users do this.

I'm not opposed to the Java style either though. (at least for me 
that would be org.webfreak instead of webfreak)

However some projects are quite generic, I think having some 
common idiom there like calling generic packages `util.atomic` or 
`util.money` would be good. Of course there might be name 
clashing with this, but it's unlikely to happen in the same 
project depending on them because packages with the same name are 
usually competing packages and not packages you would use 
together. In the case you do have an issue with overlapping 
package names you could make dub wrapper packages as well.