Dev updates

[theballaam96]

No description provided.

To fix the issue, remove the redundant inner import logging and rely on the existing top-level import logging at line 135. In general, modules should be imported once at module scope unless there is a specific need for a local or conditional import.

Concretely, in __init__.py, within the generate_early method around lines 968–974, delete the line import logging that appears just before logging.warning(...). No other changes are necessary: the logging.warning call will use the module imported at line 135. This preserves all existing behavior while cleaning up the redundant import.

In general, to fix an empty except block, either (a) add appropriate handling such as logging, cleanup, or re-raising, or (b) add a clear explanatory comment if intentional and benign. Here we can improve safety and diagnosability without changing functional behavior by logging the issue and then skipping the problematic location, matching the intent of “ignore if missing.” The earlier use site in the same function (lines 68–71) already uses continue to skip nonexistent locations, so we should mirror that explicit behavior.

Concretely, in archipelago/Rules.py, within apply_minimal_logic_rules, replace the except KeyError: pass block at lines 108–112 with a block that documents the intent and continues the loop (or simply returns to the next iteration), and optionally logs a debug message. To avoid new dependencies and minimize external assumptions, we can rely on the standard logging module, which is well-known and widely used. We will add a logging import and a module-level logger. Then, in the except KeyError: block, we log a debug message indicating the location was not found and then continue to the next loc_id in non_dk_location_ids. This preserves the current behavior of “do not crash if the location is missing,” but no longer has a completely empty handler.

In general, to fix this kind of cyclic import you remove the direct import that participates in the cycle and instead depend on something that does not itself depend back on the current module. Typical approaches include: moving the shared functionality to a third, lower‑level module; inlining very small helper logic; or passing required objects as arguments instead of importing them.

Here, ShuffleItems only needs ItemPool.Keys() to obtain the collection of key items. We can break the cycle without changing behavior by locally defining the same Keys() logic in this file (or, equivalently, by inlining the check) instead of importing ItemPool. Since we must not modify other files, the best option within this snippet is to remove the import randomizer.ItemPool as ItemPool in the conditional block and replace its usage with a small helper function that returns the key items. To avoid assumptions about the rest of the code, we can implement Keys() using the already‑imported Items enum, which is the natural place where the key items live.

Concretely:

• Add a new helper function near the top of ShuffleItems.py, e.g. def _key_items(): ..., returning the same iterable that ItemPool.Keys() would have provided. This uses Items values that correspond to keys (e.g., Items.Key1–Items.Key8 or whatever subset is applicable).
• Replace the local import import randomizer.ItemPool as ItemPool with a call to this helper, i.e., call _key_items() instead of ItemPool.Keys().
• Adjust the if condition in the loop over LevelInfoList.values() to check membership in _key_items() instead of ItemPool.Keys(). No other behavior changes are needed.

This eliminates the cycle by removing ShuffleItems’s dependency on ItemPool while preserving the semantics of “is this item a key?” as long as the helper returns the correct set of key Items values.