Thank you for helping me get the discussion into a constructive direction. I'm sorry my original post was not adequate.
On the topic of copy-pasting: I think that is a development environment issue. Ideally there were tools that adequately support the setting up of mods with some initial scaffolding customized to the particular needs of the mod. Then the decision whether to keep tight control over a particular aspect of the system or depending on an independently distributed/updated artifact would not impact the development work. I'm coming from a MDA/MDSD background, so I would look into some kind of generator, but I suspect a normal build tool like Maven or even bare make could go a long way. I've been mostly working on existing games that usually already have a framework for library functions and can't have installation time dependencies (which I sometimes feel would be nice, but can probably be solved better within the current system) I didn't yet feel the need to look into mod creation support, but e.g. see https://codeberg.org/mineclonia/mineclonia/issues/1556 for a discussion of (possibly domain specific) mod creation tools.
Since the ContentDB has no versioned dependencies (which is a good thing, IMO), I think it is usually better to keep the ability to e.g. control updates by linking modules in the development process before uploading as a (mostly) self contained artifact even if that same aspect would be left to dependency resolving during installation in other contexts.
I don't agree that my complaint is not about the content of the mod, but ok.
I agree it's fine to use a logging API. I agree its fine to have libraries in the DB.
The point raised by the first post that IMO still stands is that in this particular instance the world - IMO - would be a better place if the 75 lines of logging were copied into any mod that wants to use that API. There are aspects of software development that should be addressed within the development environment and not the distribution environment. One can argue (I think @LMD does) that they could be the same, because they definitely have some overlap, but - IMO - they shouldn't, because in the end they have very different requirements and one size doesn't fit all. And this conceptual misfit cannot be solved by the tooling. I also tried to give an example where I would draw the line between these two areas, and I don't claim that it is easy to make a clear distinction. Nonetheless in my experience this distinction really does exists and not addressing it creates trouble down the line.
I think that's where we disagree and that's fine. Software engineering is a creative process after all. But accusing me of being mean is not fine. I don't know the author of the mod and it is my professional opinion as a software engineer that the architectural decisions underlying this mod are suboptimal.
Trying to clarify: unlike e.g. the unicode_text mod this package doesn't provide any value directly to the user of minetest, but only to the development of other mods. Such content does not belong as a separate entity (aka binary dependency) into this user facing repository.
There is no mechanism in this repository to limit proliferation of such mods .It's bad enough that users get creatura, mobs_redo, etc. installed when they choose a mob related package, but at least they can somewhat associate a user visible part of the world with the package. How should a user know why they need logging, super_logging, logging_47, and logging_fork packages. This gives bad user experience.
Please don't do this.
PS: if someone thinks this is a great mod, write a positive review. Please do!
This is the wrong way to reuse code (even if it is exactly what most binary artifact dependency system do:-)
Non functional or technical artifacts should never be imported as binary dependencies, but instead have the relevant parts of the source manually copied or automatically generated into the project and managed there as part of the project, because they form part of the programming model which should not depend on external objects.
When such functions attain wide acceptance it might make sense to promote them into the games or minetest itself, but it's never useful as a binary artifact.
When replacing things with stone it should IMO still be possible to get every block in the game. I don't think you can create e.g. dirt_with_grass from other things.
But only if paired with Voxelgarden (which Unter Null was originally designed for), because VG provides a lot of the bootstrap mechanics a skyblock needs by default. The limited MTG support in this release is not very good(1) and has been removed from the current git version (that also changes lava cooling to be depth based which adds better progress).
So what does this mod add to the base game when used with Voxelgarden:
a world consisting of a single large ocean
a chest with some stones, some papyrus roots, a bit of dirt, and some saplings
the recipe for a (not very polished) grinding machine
lava cooling changed to sometimes give random ore nodes from flowing lava
recipes to create lava
Coupled with various gameplay mechanics of Voxelgarden this is (actually more than) enough to bootstrap one's own world from nearly nothing. If - like me - one doesn't know Voxelgarden yet, it also adds the fun of discovering the various neat mechanics that Voxelgarden provides for this process and the ways it differs from MTG (dirt is a falling node!!! but no need to restart, it is easy to get more dirt).
Also it is great that falling off is not fatal like in a typical skyblock.
Currently there are downsides:
Voxelgarden doesn't have any middle to late game content (like MTG), so one will need e.g. automation mods to keep having fun after the initial buildup; note that not all MTG mods are compatible with Voxelgarden
the lava cooling is a bit too easy in the released version, checking out the depth based lava cooling from git is recommended (even though building under water is a bit grindy in Voxelgarden)
there is a lot of polish missing, e.g. the generation of the inital chest may fail, and the UI of the grinder is primitive without any support for shift clicking
(1) the MTG support adds the papyrus roots to be used as a building and plant base in the ocean, but a lot of nodes are not creatable, e.g. most plants
Thank you for helping me get the discussion into a constructive direction. I'm sorry my original post was not adequate.
On the topic of copy-pasting: I think that is a development environment issue. Ideally there were tools that adequately support the setting up of mods with some initial scaffolding customized to the particular needs of the mod. Then the decision whether to keep tight control over a particular aspect of the system or depending on an independently distributed/updated artifact would not impact the development work. I'm coming from a MDA/MDSD background, so I would look into some kind of generator, but I suspect a normal build tool like Maven or even bare make could go a long way. I've been mostly working on existing games that usually already have a framework for library functions and can't have installation time dependencies (which I sometimes feel would be nice, but can probably be solved better within the current system) I didn't yet feel the need to look into mod creation support, but e.g. see https://codeberg.org/mineclonia/mineclonia/issues/1556 for a discussion of (possibly domain specific) mod creation tools.
Since the ContentDB has no versioned dependencies (which is a good thing, IMO), I think it is usually better to keep the ability to e.g. control updates by linking modules in the development process before uploading as a (mostly) self contained artifact even if that same aspect would be left to dependency resolving during installation in other contexts.
I don't agree that my complaint is not about the content of the mod, but ok.
I agree it's fine to use a logging API. I agree its fine to have libraries in the DB.
The point raised by the first post that IMO still stands is that in this particular instance the world - IMO - would be a better place if the 75 lines of logging were copied into any mod that wants to use that API. There are aspects of software development that should be addressed within the development environment and not the distribution environment. One can argue (I think @LMD does) that they could be the same, because they definitely have some overlap, but - IMO - they shouldn't, because in the end they have very different requirements and one size doesn't fit all. And this conceptual misfit cannot be solved by the tooling. I also tried to give an example where I would draw the line between these two areas, and I don't claim that it is easy to make a clear distinction. Nonetheless in my experience this distinction really does exists and not addressing it creates trouble down the line.
I think that's where we disagree and that's fine. Software engineering is a creative process after all. But accusing me of being mean is not fine. I don't know the author of the mod and it is my professional opinion as a software engineer that the architectural decisions underlying this mod are suboptimal.
Trying to clarify: unlike e.g. the unicode_text mod this package doesn't provide any value directly to the user of minetest, but only to the development of other mods. Such content does not belong as a separate entity (aka binary dependency) into this user facing repository.
There is no mechanism in this repository to limit proliferation of such mods .It's bad enough that users get creatura, mobs_redo, etc. installed when they choose a mob related package, but at least they can somewhat associate a user visible part of the world with the package. How should a user know why they need logging, super_logging, logging_47, and logging_fork packages. This gives bad user experience.
Please don't do this.
PS: if someone thinks this is a great mod, write a positive review. Please do!
This is the wrong way to reuse code (even if it is exactly what most binary artifact dependency system do:-)
Non functional or technical artifacts should never be imported as binary dependencies, but instead have the relevant parts of the source manually copied or automatically generated into the project and managed there as part of the project, because they form part of the programming model which should not depend on external objects.
When such functions attain wide acceptance it might make sense to promote them into the games or minetest itself, but it's never useful as a binary artifact.
When replacing things with stone it should IMO still be possible to get every block in the game. I don't think you can create e.g. dirt_with_grass from other things.
But only if paired with Voxelgarden (which Unter Null was originally designed for), because VG provides a lot of the bootstrap mechanics a skyblock needs by default. The limited MTG support in this release is not very good(1) and has been removed from the current git version (that also changes lava cooling to be depth based which adds better progress).
So what does this mod add to the base game when used with Voxelgarden:
Coupled with various gameplay mechanics of Voxelgarden this is (actually more than) enough to bootstrap one's own world from nearly nothing. If - like me - one doesn't know Voxelgarden yet, it also adds the fun of discovering the various neat mechanics that Voxelgarden provides for this process and the ways it differs from MTG (dirt is a falling node!!! but no need to restart, it is easy to get more dirt).
Also it is great that falling off is not fatal like in a typical skyblock.
Currently there are downsides:
(1) the MTG support adds the papyrus roots to be used as a building and plant base in the ocean, but a lot of nodes are not creatable, e.g. most plants