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.
Formaly warning for clarification or else I'll petition to turn this to a thread as it does not appear to be a valid reviewing of the package contents themselves, just random gibberish
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!
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.
This statement is false. Any library mod, including unicode text, only provides value to modders, who then use that value to create value for players. Some contributions may be more direct, but better logging may certainly benefit end users, especially as they get more technical (which does not just mean developers; there are also admins and moderators).
Such content does not belong as a separate entity (aka binary dependency) into this user facing repository.
(I still don't get why you're calling this "binary" when it's plaintext source code. That's a very confusing, fearmongering way to use the word "binary" for sure - as if this was some intransparent binary blob rather than a small piece of Lua any interested tinkerer can easily poke.)
This is where you go plain wrong. ContentDB is explicitly also a place for such dependencies, whether you like that or not. Quoting the package inclusion policy:
Adding non-player facing mods, such as libraries and server tools, is perfectly fine and encouraged. ContentDB isn't just for player-facing things, and adding libraries allows them to be installed when a mod depends on it.
In other words, you're negatively reviewing a package for doing something encouraged by the package inclusion policy.
There is no mechanism in this repository to limit proliferation of such mods
How ContentDB deals with library mods is a ContentDB problem, not a problem of this mod; and ContentDB has a tag for library mods ("API / Library").
It's bad enough that users get creatura, mobs_redo, etc. installed when they choose a mob related package
Is it though? If everything goes smoothly, I don't see any issues here. And I don't see a solid suggestion for how to handle library mods instead coming from you either.
How should a user know why they need logging, super_logging, logging_47, and logging_fork packages.
Easy: Because a mod they use depends on them. Note also that our users aren't just players, but also e.g. admins or other developers.
This gives bad user experience. Please don't do this.
Please don't do what you did here: Write a review which is not at all about the actual "content" of this library mod - the actual APIs implemented - but rather about the meta-topic of "how do we want to deal with library mods".
I frankly think you're being mean and unfair towards the author of this mod.
You have no substantial criticism relevant to what this package is about, yet gave this package a negative review.
PS: if someone thinks this is a great mod, write a positive review. Please do!
I will not write a positive review of a library mod I haven't used and potentially will not use just to balance out your unfair negative review.
API's are an essential part to developing and creating packages and content, without these public APIs in the CDB, you wouldn't be able to install or play the mods that depend on them
This is not a valid review of the package, that's why it's getting converted to a thread, it does pose valid criticism on what a non developer sees when they interact with so many APIs and apparently "useless" packages in the CDB, as @LMD explained already, they are an essential part of the user experience :)
Please note that reviews are meant to comment on the package contents themselves, not on CDB policy or bug/issue reporting!
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.
Thanks for the clarification. In light of it, please let me apologize for insinuating that you were being mean towards the mod author. (I believe I owe you an explanation: I simply had not seen a direct connection between your review and this mod initially. It seemed to me as if you were not reviewing their mod specifically, but rather voicing generic criticism not specific to this mod.)
Given this clarification, ContentDB staff might want to reconsider whether this would qualify as a review.
@j-r, this API is used by 12 mods, your suggestion to include the 75 lines of code this mod provides in those 12 mods, and any subsequent mods that use it, would mean an increase in 10 times the amount of repeated lines of code, and also would create a complicated landscape when it comes to maintaining such mods and this API
The way it is now, if you wish, you can install all the mods under the section "Required By" of page https://content.minetest.net/modnames/logging/, plus this API (which will be installed automatically given you use the MT client), and have all those mods work perfectly fine with each other, because they all depend on the same version and code from this API package, which is a given when you depend on a package; if it were like you suggest, and each were to provide their own logging API, it would probably cause conflicts with eachother, or not, but there would be no way to know for sure unless you keep all your packages perfectly updated and in sync with each other
The concept of libraries and APIs being distributed and used as dependencies is common within most landscapes developers traverse, BUT, I do agree that they don't serve immediate value to the end-user, and I believe that's where your comments come from, that's why I've filed issue #544 on the ContentDB's Github page
@LMD we won't turn this thread back to a review. This is because we feel it's not directly connected to the package itself, and more to the general landscape of the ContentDB, and thus is not a valid review of this package's contents, plus it not being fair to the author of the package to receive a negative review on something unrelated to the content itself
On a more presonal level, I also want to add that I generally agree with the methodology of copy-pasting static code from one project to the next, but if you know you will be using a helper function in 100 different projects, it may just be better to save yourself the copy pasting and make a library out of it, put it up, and just use that instead
Also 75 lines is beyond my practical copy-pasting limits for reusing code
Hell, if you are using the same 75-liner function over multiple packages, it's probably because it's useful, and it's okay to post it up as a standalone package so other people can benefit from it too, without the need to copy-paste code that is not theirs, and without the need to deal with the licensing that comes afterwards (one thing is copying 5 lines from stack overflow, the other is copying a script closer to a hundred lines)
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.
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.
I'm not sure where you see any "binary dependencies" here.
Formaly warning for clarification or else I'll petition to turn this to a thread as it does not appear to be a valid reviewing of the package contents themselves, just random gibberish
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 statement is false. Any library mod, including unicode text, only provides value to modders, who then use that value to create value for players. Some contributions may be more direct, but better logging may certainly benefit end users, especially as they get more technical (which does not just mean developers; there are also admins and moderators).
(I still don't get why you're calling this "binary" when it's plaintext source code. That's a very confusing, fearmongering way to use the word "binary" for sure - as if this was some intransparent binary blob rather than a small piece of Lua any interested tinkerer can easily poke.)
This is where you go plain wrong. ContentDB is explicitly also a place for such dependencies, whether you like that or not. Quoting the package inclusion policy:
In other words, you're negatively reviewing a package for doing something encouraged by the package inclusion policy.
How ContentDB deals with library mods is a ContentDB problem, not a problem of this mod; and ContentDB has a tag for library mods ("API / Library").
Is it though? If everything goes smoothly, I don't see any issues here. And I don't see a solid suggestion for how to handle library mods instead coming from you either.
Easy: Because a mod they use depends on them. Note also that our users aren't just players, but also e.g. admins or other developers.
Please don't do what you did here: Write a review which is not at all about the actual "content" of this library mod - the actual APIs implemented - but rather about the meta-topic of "how do we want to deal with library mods".
I frankly think you're being mean and unfair towards the author of this mod.
You have no substantial criticism relevant to what this package is about, yet gave this package a negative review.
I will not write a positive review of a library mod I haven't used and potentially will not use just to balance out your unfair negative review.
converted review into a thread
API's are an essential part to developing and creating packages and content, without these public APIs in the CDB, you wouldn't be able to install or play the mods that depend on them
This is not a valid review of the package, that's why it's getting converted to a thread, it does pose valid criticism on what a non developer sees when they interact with so many APIs and apparently "useless" packages in the CDB, as @LMD explained already, they are an essential part of the user experience :)
Please note that reviews are meant to comment on the package contents themselves, not on CDB policy or bug/issue reporting!
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.
Thanks for the clarification. In light of it, please let me apologize for insinuating that you were being mean towards the mod author. (I believe I owe you an explanation: I simply had not seen a direct connection between your review and this mod initially. It seemed to me as if you were not reviewing their mod specifically, but rather voicing generic criticism not specific to this mod.)
Given this clarification, ContentDB staff might want to reconsider whether this would qualify as a review.
@j-r, this API is used by 12 mods, your suggestion to include the 75 lines of code this mod provides in those 12 mods, and any subsequent mods that use it, would mean an increase in 10 times the amount of repeated lines of code, and also would create a complicated landscape when it comes to maintaining such mods and this API
The way it is now, if you wish, you can install all the mods under the section "Required By" of page https://content.minetest.net/modnames/logging/, plus this API (which will be installed automatically given you use the MT client), and have all those mods work perfectly fine with each other, because they all depend on the same version and code from this API package, which is a given when you depend on a package; if it were like you suggest, and each were to provide their own logging API, it would probably cause conflicts with eachother, or not, but there would be no way to know for sure unless you keep all your packages perfectly updated and in sync with each other
The concept of libraries and APIs being distributed and used as dependencies is common within most landscapes developers traverse, BUT, I do agree that they don't serve immediate value to the end-user, and I believe that's where your comments come from, that's why I've filed issue #544 on the ContentDB's Github page
@LMD we won't turn this thread back to a review. This is because we feel it's not directly connected to the package itself, and more to the general landscape of the ContentDB, and thus is not a valid review of this package's contents, plus it not being fair to the author of the package to receive a negative review on something unrelated to the content itself
On a more presonal level, I also want to add that I generally agree with the methodology of copy-pasting static code from one project to the next, but if you know you will be using a helper function in 100 different projects, it may just be better to save yourself the copy pasting and make a library out of it, put it up, and just use that instead
Also 75 lines is beyond my practical copy-pasting limits for reusing code
Hell, if you are using the same 75-liner function over multiple packages, it's probably because it's useful, and it's okay to post it up as a standalone package so other people can benefit from it too, without the need to copy-paste code that is not theirs, and without the need to deal with the licensing that comes afterwards (one thing is copying 5 lines from stack overflow, the other is copying a script closer to a hundred lines)
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.