mt-mods / mail

Mail mod for Minetest
https://content.minetest.net/packages/mt-mods/mail/
Other
14 stars 22 forks source link

De-bundle unspecific stuff #146

Open Athozus opened 5 months ago

Athozus commented 5 months ago

Yo,

I initially planned this in my mind for 1.5.0, but as 1.4.0 is getting more and more "late" (that's a volunteer project at all), so I'm opening the issue right now and I did not set a milestone, to be discussed.

IMHO, we should the following stuff :

All those dependencies of mail mod, all managed by mt-mods, and for all I assume the "unofficial" role of (co-)maintainer.

BuckarooBanzay commented 4 months ago

are those functions/features already used elsewhere?

Athozus commented 4 months ago

No, they are not. But GUI helpers could be used for every Minetest mod using formspec, and settings for example with i3 which is using settings.

And anyway, it's like the wrench which has its own mod now, because it was unrelated to technic. This one, we have a lot of helpers that are not directly related to mail, so why not share them ?

S-S-X commented 4 months ago

This one, we have a lot of helpers that are not directly related to mail, so why not share them ?

Mostly commenting and adding reasoning for "why not?" part:

Can you prove, through actual use cases and API stability stats, that those are actually good enough for real generic use?

Many library projects fail because of trying to provide useful and generic stuff without really field testing it first, and when you fail once people will remember not to waste time with it again. Doesn't matter if you fix the issues.

OgelGames commented 4 months ago

It only really makes sense to create a library mod when code is already being copy-pasted between mods, vizlib and xcompat are good examples of this. In this case, I think it's a bad idea.

And anyway, it's like the wrench which has its own mod now, because it was unrelated to technic.

That's a bad comparison. The wrench mod was separated to make it easier to maintain, and because it could be used without technic, it made sense to make it available separate from the modpack.

Athozus commented 4 months ago

Can you prove, through actual use cases and API stability stats, that those are actually good enough for real generic use?

i3 has also a special GUI customization, that could be merged with the utilities from mail (same for i3 settings, some advtrains user-settings, etc.). And without thinking about i3 or advtrains, it is just that mail mod initialize a lot of utilities that are not intended to be used only with mail mod, so why not debundle these directly ?

Many library projects fail because of trying to provide useful and generic stuff without really field testing it first, and when you fail once people will remember not to waste time with it again. Doesn't matter if you fix the issues.

Yes, but some have worked (e.g. GTK :wink:)

That's a bad comparison. The wrench mod was separated to make it easier to maintain, and because it could be used without technic, it made sense to make it available separate from the modpack.

Yes, and mail.get_color(), ... can be used without mail mod :slightly_smiling_face:

Athozus commented 3 months ago

Btw I'm still waiting for getting the right to close this to release 1.4.

Athozus commented 1 month ago

1.4 is waited for a long time, I move that to 1.5