Naming convention for library mods

[orwell]

Hi everyone,

Over time, many mods have emerged that do not add content on their own, but merely provide functionality for other mods to use. They are often referred to as "library mods" or "libraries".

Some modders like to express this fact by a certain prefix or suffix in the mod name. However, there is no consistent standard. Naming schemes I've seen so far are:

• foobar - no prefix/suffix at all, appears to be the most widely used variant
• foobar_lib - used by most "established" libraries such as signs_lib
• foobarlib - also used sometimes, e.g. cmdlib, intllib
• lib_foobar - particularily used by ShadMOrdre, e.g. lib_clouds, lib_emerge
• libfoobar - the Unix naming scheme, seldom used
• foobar_api - e.g. w_api

In my opinion, it would be good to agree on one common naming scheme as a community.

• What is your opinion on this?
• Which other naming schemes do you suggest?

TL;DR

• Making "libraries" by exposing interfaces in the global namespace is bad practice, it would be better to utilize require().
• The content DB has to be extended to properly function as "package manager" for libraries, and maybe allow different versions of the same library to be installed a.s.o.

(I will continously update this)

*) Just to collect opinions, I am aware that this is still bad practice, but I think we won't come up with a better solution in the near future.

[v-rob]

I personally like foobar_lib, which seems the most prevalent in the Minetest Forums besides ones without any lib at all. It makes sense, too. Would you say "the Signs library" or "the library of Signs"? Of course, another thing that merits discussion is the API namespace. For instance, foobar_lib.func() and foobar.func() are two very different things when typed over and over. So, that also deserves discussion in this as well. Should the API and the name be the same? If so, that probably changes what the name should be.

[Linuxdirk]

For APIs I prefer foobar_api, for libraries I prefer lib_foobar.

[texmex]

foobar. Because a large amount of mods come with library functions, API and content bundled anyway.

[Termos]

foobar is fine.

More interesting question, how to keep other people from releasing mods containing modified versions of foobar table under the same name.

[joe7575]

...and even more interesting: How to distinguish different incompatibel versions from one library. Do we need a number prefix like foobar1 and foobar2

[texmex]

And so we arrive yet once more at need of a minetest package manager.

Ideally we'd use the LuaRocks infrastructure but since Lua can't be properly sandboxed in Minetest without foregoing the require() function it's up to the devs to implement a custom one.

[sorcerykid]

Over half of the mods I've developed are libraries. I always name them like any other mod since they usually provide both an API and some type of user-facing functionality, like a GUI console, chat command, etc.

• scarlet
• formspecs
• auth_rx
• markup
• avatars
• finder
• axon
• physics
• sentinel
• registry
• config
• stopwatch
• antigrief
• city_block
• safety_deposit
• cipher
• polygraph
• imagen
• ownership
• bitwise
• collections
• launchpad
• about

The only repository I've named as "lib" is rocketlib and that's because it truly is a standalone library, independent of the Minetest framework.

Frankly, I think the implementation of Minetest "libraries" is an anti-pattern because their interfaces must be exposed by polluting the global namespace. That is a baffling design decision and one that defies conventional Lua programming practices that aim for modularity and abstraction. The notion of using global variables to access an API still makes my head spin to this day :)

[Linuxdirk]

And so we arrive yet once more at need of a minetest package manager.

Everything is there in the CDB, it just has to be used in the client.

[texmex]

And so we arrive yet once more at need of a minetest package manager.

Everything is there in the CDB, it just has to be used in the client.

Yes, fortunaly rubenwardy has his eyes on the task.

[orwell]

And so we arrive yet once more at need of a minetest package manager.

Everything is there in the CDB, it just has to be used in the client.

I think the point in here is to also be able to specify the library version, to ensure compatibility.
We also have the classical example of mobs vs. mobs redo. Tenplus1 solved the version detection problem by adding mobs.mod="redo" or so, and other modders have adopted this.

Frankly, I think the implementation of Minetest "libraries" is an anti-pattern because their interfaces must be exposed by polluting the global namespace. That is a baffling design decision and one that defies conventional Lua programming practices that aim for modularity and abstraction. The notion of using global variables to access an API still makes my head spin to this day :)

I agree clearly. But I don't think we will have a better library handling in the near future, and until then we need to stick to the current solution.

[sorcerykid]

Relevant post from a different topic, but it touches upon so many points raised in this discussion.

https://forum.minetest.net/viewtopic.php?p=351175#p351175

[sorcerykid]

I agree clearly. But I don't think we will have a better library handling in the near future, and until then we need to stick to the current solution.

That's probably going to change in the next couple days when I release my Pluggable Helpers mod that provides automatic dependency management for helper functions, helper classes, and helper modules ;).

[v-rob]

I agree clearly. But I don't think we will have a better library handling in the near future, and until then we need to stick to the current solution.

That's probably going to change in the next couple days when I release my Pluggable Helpers mod that provides automatic dependency management for helper functions, helper classes, and helper modules ;).

I think it's really sad to think how few people use your libraries. I think the main problem is people thinking "I want my code to be as small as possible, so I won't touch any other libraries" as well as modders not wanting users to have to worry about dependencies. I don't think people will start to use libraries until Minetest has some sort of built-in support for them. I don't think anyone will want to use your management system because they think that they will be the only one using it, and it's probably fairly useless at that point.

I mean, I don't know anything for certain, but that's the general trend I've noticed.

[rubenwardy]

Obviously, the compromise here is to name them lib_foorbarlib_api

[orwell]

I think it's really sad to think how few people use your libraries. I think the main problem is people thinking "I want my code to be as small as possible, so I won't touch any other libraries" as well as modders not wanting users to have to worry about dependencies. I don't think people will start to use libraries until Minetest has some sort of built-in support for them. I don't think anyone will want to use your management system because they think that they will be the only one using it, and it's probably fairly useless at that point.

I mean, I don't know anything for certain, but that's the general trend I've noticed.

Indeed, sorcerykid's work on this is impressive. I plan to use imagen to draw track maps for advtrains, and am thinking about porting some/all of advtrains' formspecs to ActiveFormspec. It's just that I lack time to do that currently...

[v-rob]

Indeed, sorcerykid's work on this is impressive. I plan to use imagen to draw track maps for advtrains, and am thinking about porting some/all of advtrains' formspecs to ActiveFormspec. It's just that I lack time to do that currently...

I am planning at some point to make a canvas formspec element; I just haven't figured out how to draw irregular polygons with Irrlicht. Imagen is really cool, but I can't stand the thin lines :)

[ShadMOrdre]

I feel like I should chime in here.

I initially chose the lib_ name scheme to have my mods, or customizations of others mods, show up in the list in an obvious way. Poor reason, but I stuck with it.... :(

However, I would like to point out that lib_mat / lib_eco are libraries, in a sense. The code was written to be usable by both mods and games. It still is not complete, in that regard, but is closer to the goal than not.

As for the content provided with those mods, they are a content library. Hence the name....


All that aside,

I have previously proposed, and have utilized the following type of scheme.

Since all games must have a mod, and some minimum setup for the engine, I proposed the Game mod. This mod handles the basic setup. Essentially what paramat has currently posted with the minipelli game. But I wouldn't stop there. I would have the game mod do "EVERYTHING". But not in the MTG/default kinda way. All registrations would be registered to the Game mod. Mods would no longer have to depend on a multitude of mods, just the one, with all registrations being handle therein. The Game mod would also include an API and lib registration. If the code is registered, at runtime, dependencies become irrelevant, simply because all code can be ensured to be loaded and available.

I'll try to get my working example posted on github, and to make a forum topic.

This is not to suggest that any of sorcerykids work is not usable or otherwise. I just haven't found a need for any of those mods......yet. I am keeping an eye on the formspecs, not from a gameplay, user interactable way, but simply to provide attractive info screens to players. I personally abhore using formspecs for any game play functionality, because it suspends, or outright destroys immersion.


Shad