Suggestion for DUB users: The vanity package

[Steven Schveighoffer]

On 10/19/21 12:37 PM, Kagamin wrote:
> On Tuesday, 19 October 2021 at 04:03:38 UTC, Mathias LANG wrote:
>> 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.
> 
> If we can have several libraries starting with com and org, why not have 
> a default package `d` or `dlang` used by everyone, so it would be
> module d.bitblob;

Note that the vanity package needs to be a name that isn't used anywhere 
else. Even with the module under a package, the problem is still present 
with the *top level package*. e.g. `std` is not a common name used by 
anyone, so it causes little grief.

Something like `geod24` is not going to be a common name. But `d` likely 
is. I don't think `dlang` would be a bad idea, but I suggest actually 
something really unlikely. But it is a good idea to have a specific 
language-sanctioned "put your one module projects here".

I've been using `schlib` for [my 
stuff](https://github.com/schveiguy/lookuptable).

-Steve