| Time |
Nick |
Message |
| 02:25 |
|
queria joined #minetest-dev |
| 03:00 |
|
specing_ joined #minetest-dev |
| 03:47 |
|
Kimapr joined #minetest-dev |
| 04:40 |
|
Kimapr1 joined #minetest-dev |
| 05:50 |
|
ssieb joined #minetest-dev |
| 07:10 |
|
longerstaff13 joined #minetest-dev |
| 07:17 |
|
entuland joined #minetest-dev |
| 07:17 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:51 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:55 |
|
tech_exorcist joined #minetest-dev |
| 09:02 |
|
queria joined #minetest-dev |
| 09:33 |
|
calcul0n__ joined #minetest-dev |
| 10:10 |
|
appguru joined #minetest-dev |
| 11:13 |
|
calcul0n__ joined #minetest-dev |
| 11:21 |
|
appguru joined #minetest-dev |
| 12:01 |
|
appguru joined #minetest-dev |
| 12:03 |
appguru |
Krock: Here's a Lua PoC for hard dependency load order using DFS as mentioned by ruben: https://gist.github.com/appgurueu/b323dc18c3e99f05bb98318d3ab335ae |
| 12:04 |
appguru |
That also generates useful error messages for circular dependencies using a singly linked list |
| 12:05 |
appguru |
Soft dependencies unfortunately aren't as easy. Ruben's proposal of just silently ignoring cycles doesn't work. |
| 12:08 |
appguru |
Well it does work, but I'm pretty sure it doesn't guarantee maximization of fulfilled soft dependencies. |
| 12:42 |
|
MTDiscord3 joined #minetest-dev |
| 12:53 |
|
appguru joined #minetest-dev |
| 12:59 |
|
twoelk joined #minetest-dev |
| 14:09 |
rubenwardy |
I didn't say silently ignore cycles? |
| 14:09 |
rubenwardy |
Soft dependencies should act like hard dependencies if the depended on mod is present and enabled |
| 14:17 |
sfan5 |
that sounds reasonable |
| 14:17 |
sfan5 |
do a pass before resolving dependencies where soft deps that exist are turned into hard deps and the rest thrown away |
| 14:44 |
|
Fixer joined #minetest-dev |
| 15:00 |
|
specing_ joined #minetest-dev |
| 15:18 |
|
nrz joined #minetest-dev |
| 16:01 |
sfan5 |
pushing http://sprunge.us/fVwSFv?diff in 5m |
| 16:04 |
sfan5 |
uh somehow that's missing part of the changes |
| 16:05 |
sfan5 |
just imagine the diff goes on and adds an elseif |
| 16:34 |
|
tech_exorcist joined #minetest-dev |
| 18:06 |
Krock |
<rubenwardy> Soft dependencies should act like hard dependencies if the depended on mod is present and enabled |
| 18:06 |
Krock |
and this caused problems when a mod couldn't be laoded |
| 18:06 |
Krock |
and the entire soft-dependency chain would collapse as well |
| 18:07 |
rubenwardy |
it doesn't - because now the game stops loading rather than silently disabling mods |
| 18:07 |
rubenwardy |
so the user can disable the soft depended on mods that can't load |
| 18:07 |
Krock |
but stopping there for each mod is tiring. an entire list of dependency issues is much more favourable |
| 18:08 |
Krock |
i.e. when multiple hard dependencies are missing |
| 18:08 |
rubenwardy |
rather than Minetest itself disabling the mod softed depended mods and other mods that soft depend on it |
| 18:08 |
Krock |
otherwise it's a try&error&repeat cycle |
| 18:08 |
rubenwardy |
yeah that's possible without any graph stuff - just look for the existence of mods |
| 18:08 |
Krock |
yes of course. the current approach is not good either |
| 18:09 |
Krock |
yet that existence check does not ensure logical integrity |
| 18:09 |
Krock |
such as loops |
| 18:09 |
rubenwardy |
which is why you can do graph logic to check for loops |
| 18:10 |
Krock |
ah. you're speaking of two checks. one for missing dependencies, and another for loops, as demonstrated in your code |
| 18:10 |
Krock |
what I want is a list of erroneous mods |
| 18:11 |
MTDiscord |
<appguru> the code I provided does exactly that, Krock |
| 18:11 |
Krock |
checking rn |
| 18:11 |
MTDiscord |
<appguru> by keeping the path (the cycle) as a linked list |
| 18:11 |
MTDiscord |
<appguru> note that a soft dependency cycle should not trigger an error however |
| 18:12 |
rubenwardy |
it should |
| 18:12 |
rubenwardy |
soft dependencies require that the dependency loads before a depender |
| 18:12 |
rubenwardy |
it's soft because the dependency doesn't need to exist. But if it does, it should load before |
| 18:12 |
rubenwardy |
so cycles with soft dependencies should cause an error |
| 18:13 |
rubenwardy |
as said "soft dependencies should act like hard dependencies if the depended on mod is present and enabled" |
| 18:13 |
rubenwardy |
there's no meaning for a soft dependency where the mod doesn't need to load before |
| 18:13 |
Krock |
they're soft because they're optional |
| 18:13 |
rubenwardy |
yeah |
| 18:13 |
rubenwardy |
that's a better term sorry |
| 18:14 |
rubenwardy |
the opposite of optional is required though, and required dependency sounds silly |
| 18:14 |
Krock |
which again means that the dependencies are not necessary met |
| 18:14 |
rubenwardy |
There is some usefulness in having hard deps which don't need to load before - perhaps you don't need them at load time, and want to avoid cycles |
| 18:15 |
Krock |
hmm |
| 18:15 |
Krock |
currently there's no way to indicate that |
| 18:16 |
rubenwardy |
I'd also like to add "provides" as well. For example, it's too late for mobs redo but really its mod name should be `mobs_redo` and it should "provide" the `mobs` name |
| 18:16 |
Krock |
and I haven't seen any such problem so far |
| 18:16 |
rubenwardy |
and then mods could depend on `mobs_redo` specifically, or `mobs` generally |
| 18:17 |
Krock |
that's what "name = xxx" does |
| 18:17 |
rubenwardy |
that's a bit messy though, you can't install multiple at a time and it gets hard for ContentDB to resolve |
| 18:17 |
rubenwardy |
you also can't specifically say you want a fork or versions like a fork |
| 18:17 |
Krock |
depending on a group of mods is an easy cause for compatibility issues |
| 18:18 |
Krock |
they would have to be API-compatible which is hardly possible IMO |
| 18:19 |
rubenwardy |
we already have this situation with mod names, but worse as mods then must share a name |
| 18:19 |
rubenwardy |
also this is sidetracking massively |
| 18:39 |
|
behalebabo joined #minetest-dev |
| 19:04 |
pgimeno |
isn't there a need for a mod to specify "I depend on this mod, but it does not necessarily need to be loaded before me"? |
| 19:04 |
MTDiscord |
<Jonathon> No? |
| 19:05 |
MTDiscord |
<Jonathon> More like i need one mod or another |
| 19:05 |
MTDiscord |
<Jonathon> Because right now the best solution is to put them both as optional and then check to see if either or exists |
| 19:06 |
Krock |
pgimeno: that's what technically optional dependencies should do IMO. but there's a little conflict of interests |
| 19:07 |
pgimeno |
it looks like this was never given enough thought and we've ended up with a mess |
| 19:09 |
Krock |
yes |
| 19:15 |
pgimeno |
I'm not sure I agree with rubenwardy. In case a circular dependency is found and an optional dependency is part of the chain, there's always the option of treating the depended mod as absent and go on. |
| 19:16 |
pgimeno |
I don't see it as an error, but as a warning. |
| 19:19 |
pgimeno |
"Warning: mod x depends on mod y, but it may not be able to take advantage of it due to a circular dependency" |
| 19:38 |
rubenwardy |
That's invalid, because in that case a mod will load before it's dependency |
| 19:38 |
rubenwardy |
It needs to throw an error, or disable mods like it does now |
| 19:39 |
rubenwardy |
Otherwise you will break guarantees |
| 19:40 |
rubenwardy |
How optional dependencies works does make sense |
| 19:40 |
rubenwardy |
But it would be nice to have a way to make dependencies without forcing orders, to help avoid cycles |
| 19:41 |
rubenwardy |
Optional dependencies without requiring they load first has no meaning at all, other than a recommendation to the user |
| 19:41 |
Krock |
the order would be nice to have |
| 19:41 |
Krock |
either the dependency (i.e. order) is fulfilled or not |
| 19:42 |
pgimeno |
yes, I've been thinking about "informational dependencies" too. Kinda like Debian's "suggests" |
| 19:43 |
pgimeno |
a way of informing the user that "this mod can make use of this other mod if installed" |
| 19:43 |
rubenwardy |
Say you optionally depend on the stairs mod - you need it to load first if it is installed, otherwise the API won't be available at load time |
| 19:43 |
pgimeno |
that's right, but what happens when not? |
| 19:44 |
rubenwardy |
It will crash if the mod is enabled and not loaded first |
| 19:44 |
pgimeno |
crash? |
| 19:44 |
rubenwardy |
If the mod isn't enabled then it will skip registering stairs |
| 19:44 |
pgimeno |
it's optional, it should work without it |
| 19:44 |
rubenwardy |
Mods use Minetest.get_modpath to check whether a mod is available |
| 19:45 |
pgimeno |
isn't that a mod bug? |
| 19:45 |
rubenwardy |
No |
| 19:45 |
rubenwardy |
Also, if you require them to check for globals, you know have a UX problem |
| 19:45 |
rubenwardy |
Because they have enabled the dependency mod, but due to a mod cycle another mod isn't registering stairs |
| 19:46 |
rubenwardy |
Optional dependencies must load before the depender, this is guaranteed by the Lua API |
| 19:46 |
rubenwardy |
But we can add new depend types that don't enforce ordering |
| 19:47 |
pgimeno |
I mean, the decision of whether to use an optional mod should be made at initialization, and stick to it during normal runtime; I consider doing otherwise a mod bug |
| 19:47 |
rubenwardy |
Still a UX issue, and breaks guarantees |
| 19:47 |
rubenwardy |
You want 3 or 4 depend types here |
| 19:48 |
rubenwardy |
(required, optional) * (sorted, unsorted) |
| 19:49 |
pgimeno |
optional unsorted is purely informational |
| 19:49 |
rubenwardy |
yeah |
| 19:49 |
rubenwardy |
optional unsorted would be essentially be "suggested" |
| 19:50 |
rubenwardy |
required unsorted would be useful for avoiding cycle issues when you don't need to use the mod at load time |
| 19:50 |
pgimeno |
yes, that's the reason for my earlier question (that Jonathon responded negatively) |
| 19:53 |
rubenwardy |
anyway, back to the new mod order algorithm - there's a potential API breakage: where a game includes hard dependencies. Sometimes this is a bug, other times it's done to enable functionality when a third-party mod is installed |
| 19:55 |
sfan5 |
reminder #11287 |
| 19:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI |
| 19:57 |
pgimeno |
hmm, come to think about it, a game could be one "root" mod plus a list of dependencies (made available in the game directory) |
| 19:57 |
pgimeno |
maybe it's that way already, I haven't paid enough attention to that part |
| 19:59 |
pgimeno |
it's not difficult to establish a loading order, look up 'topological sorting' |
| 20:00 |
MTDiscord |
<appguru> what ruben described is effectively topological sorting |
| 20:01 |
pgimeno |
that's what you use when you have a partial order (like that of "X must be loaded before Y" when not all mods specify that) |
| 20:01 |
pgimeno |
yeah |
| 21:50 |
|
Extex joined #minetest-dev |
| 23:57 |
|
Alias2 joined #minetest-dev |
