www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Best practice for dub registry package and module names

reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
Let's say I have three modules that work together, which I want to 
register on dub: A, B, and C.

Although the most interesting one is C and A and B are used in its 
implementation, A and B can be registered individually as well and be 
used as C's dependencies.

I know package-less modules are more prone to name collisions; so I 
would like to give package names to these three modules.

Should the package name be the same as each module? a.a, b.b, and c.c?

Should the package be the author's name: acehreli.a, acehreli.b, and 
acehreli.c?

Should they somehow reflect what they do: storage.a, buffer.b, and cache.c?

What about module names? If the type is 'struct MyCache', should the 
module name be mycache, or my_cache, or my-cache?

What else?

Thank you,
Ali
Sep 03 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
This slightly smells, single module dub packages.

What does each module do?
Sep 03 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/3/22 20:04, rikki cattermole wrote:

 This slightly smells, single module dub packages.

 What does each module do?


The other issue is NIH because some of their functionality already 
exists. :/

A: Block of elements

B: Expanding circular buffer

C: Cache of elements

I would like to register only C. However, B and A can be useful 
individually as well.

My conflict stems from the fact that e.g. 'import block;' may collide 
with the user's own 'block'. There better be some namespacing, no?

Ali
Sep 03 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Yeah you're over thinking this.

It is a single dub package with a namespacing package directory.
Sep 03 2022
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/3/22 20:39, Ali Çehreli wrote:

For example, there is fixedsizearray, which does not belong to any package:

   https://code.dlang.org/packages/fixedsizearray

On the other hand, arsd-official:minigui does have a package. (And that 
answers a question: Dash character is acceptable in package and module 
names.)

   https://code.dlang.org/packages/arsd-official%3Aminigui

How does that work? When the following dependency added to a user's project,

   "arsd-official:minigui": "~>10.9.1"

does dub pull the entirety of arsd-official and then use minigui module 
from it? I think so, because minigui has dependencies to the same 
package which are (I think) not specifiable in dub.

So, if I register the C package, B and A will be available under it and 
the users can use A and B. I think I need to get used to the feeling of 
wastefulness for pulling the entire package. :/

Ali
Sep 03 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
I cannot recommend looking at how Adam has done it.

I've been trying to get him to change it since he originally did it.

It has known issues and yes it will still pull in all modules thanks to 
-I behavior except you get fun things like linker errors.

Keep in mind, you are trying to optimize development & maintenance time 
associated with build & package management. Not optimize for quickest 
build times. So it isn't wasteful, you're just focusing on a different 
metric.
Sep 03 2022
prev sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 4 September 2022 at 03:50:56 UTC, Ali Çehreli wrote:

 For example, there is fixedsizearray, which does not belong to 
 any package:


Yeah, this is bad design since two separate people might reuse 
the name and then end users - even if it comes through a couple 
layers of dependencies they didn't even know about - can see 
conflicts when they try to link the program.

You really need globally unique D names.


 On the other hand, arsd-official:minigui does have a package. 
 (And that answers a question: Dash character is acceptable in 
 package and module names.)


dub allows dash. D does not. The dub name and the D name do not 
have to match (I personally consider this yet another design flaw 
in dub, but it is what it is).

The reason mine is called "arsd-official" on dub is because 
someone else registered "arsd" before me, but they didn't keep up 
with changes, so I had to do it myself but the name was already 
taken.

But remember, the dub package name and the D package/module names 
are completely separate. D knows absolutely nothing about dub and 
dub knows very little about D. You should have them match when 
you can for user convenience, but it doesn't actually check it.


 How does that work? When the following dependency added to a 
 user's project,

   "arsd-official:minigui": "~>10.9.1"

 does dub pull the entirety of arsd-official and then use 
 minigui module from it?


Yes, dub always pulls its top level thing in full. Then I had to 
specify a long list of subpackages in dub.json to let it 
understand the independent modules.

Dub is unbelievably and embarrassingly bad. It really is a 
disappointment, but you can make it somewhat work if you repeat 
yourself enough times. Downloading a few extra kilobytes of D 
code is the least of its problems.
Sep 04 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Sunday, 4 September 2022 at 01:52:11 UTC, Ali Çehreli wrote:

 Let's say I have three modules that work together, which I want 
 to register on dub: A, B, and C.



You should learn `ARSD`, and become `Ali-official`.
Sep 03 2022
prev sibling next sibling parent Mathias LANG <pro.mathias.lang gmail.com> writes:
On Sunday, 4 September 2022 at 01:52:11 UTC, Ali Çehreli wrote:

 Should the package be the author's name: acehreli.a, 
 acehreli.b, and acehreli.c?


I use this approach:
https://forum.dlang.org/thread/jdkmtgftmwtwaxxqhlju forum.dlang.org
Sep 03 2022
prev sibling next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 4 September 2022 at 01:52:11 UTC, Ali Çehreli wrote:

 Should the package be the author's name: acehreli.a, 
 acehreli.b, and acehreli.c?


This is what I'd suggest. You want something that nobody else is 
likely to step on throughout the entirety of the D ecosystem. It 
doesn't have to literally be your name, but it should be 
something unique and probably arbitrary at the top level. This 
way you can use it as much as you want without worrying about 
conflicting with someone else.

Then you have the more descriptive name as the module.

Your dub package name is then a combination of these to make that 
unique too. So you might have dub package `acehreli-a` which has 
the D module `acehreli.a`.


 What about module names? If the type is 'struct MyCache', 
 should the module name be mycache, or my_cache, or my-cache?


Module names must be valid D identifiers, so no dash there. 
Whether you use _ or squeeze the words together is up to you, I'd 
say pick whichever one is easier to read.

I usually squeeze words together.
Sep 04 2022
prev sibling parent Vijay Nayar <madric gmail.com> writes:
On Sunday, 4 September 2022 at 01:52:11 UTC, Ali Çehreli wrote:

 Let's say I have three modules that work together, which I want 
 to register on dub: A, B, and C.


Here I would take inspiration from the Java world, where a 
"domain" is used per project. Typically this domain is written 
from the most general part of the domain to the most specific, so 
"web.example.com" becomes "com.example.web".

For example:
```
import org.springframework.boot.SpringApplication;
```

So you could have: com.alicorp.a, com.alicorp.b, and com.alicorp.c

That being said, D is not Java, thus things like the company 
top-level domain could be left out and you end up with alicorp.a, 
alicorp.b, etc.

Thus the problem of name collision goes away until someone else 
tries to take the name "alicorp". I believe this is why Java uses 
the full domain, because unique domain ownership is already a 
solved problem, they just ride along.

Packages like `vibe` follow a similar mechanism, where all the 
useful modules and packages are nested under a single package.
Sep 06 2022