digitalmars.D.learn - Best practice for dub registry package and module names
- =?UTF-8?Q?Ali_=c3=87ehreli?= (16/16) Sep 03 2022 Let's say I have three modules that work together, which I want to
- rikki cattermole (2/2) Sep 03 2022 This slightly smells, single module dub packages.
- =?UTF-8?Q?Ali_=c3=87ehreli?= (11/13) Sep 03 2022 The other issue is NIH because some of their functionality already
- rikki cattermole (2/2) Sep 03 2022 Yeah you're over thinking this.
- =?UTF-8?Q?Ali_=c3=87ehreli?= (16/16) Sep 03 2022 On 9/3/22 20:39, Ali Çehreli wrote:
- rikki cattermole (8/8) Sep 03 2022 I cannot recommend looking at how Adam has done it.
- Adam D Ruppe (24/34) Sep 04 2022 Yeah, this is bad design since two separate people might reuse
- zjh (2/4) Sep 03 2022 You should learn `ARSD`, and become `Ali-official`.
- Mathias LANG (3/5) Sep 03 2022 I use this approach:
- Adam D Ruppe (15/19) Sep 04 2022 This is what I'd suggest. You want something that nobody else is
- Vijay Nayar (19/21) Sep 06 2022 Here I would take inspiration from the Java world, where a
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
This slightly smells, single module dub packages. What does each module do?
Sep 03 2022
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
Yeah you're over thinking this. It is a single dub package with a namespacing package directory.
Sep 03 2022
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
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
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
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
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
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
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