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
.
Thread overview | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 03, 2022 Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
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 |
September 04, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | This slightly smells, single module dub packages. What does each module do? |
September 04, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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 |
September 03, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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 |
September 03, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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 |
September 04, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | Yeah you're over thinking this. It is a single dub package with a namespacing package directory. |
September 04, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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. |
September 04, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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 |
September 04, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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. |
September 04, 2022 Re: Best practice for dub registry package and module names | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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. |