| Commit message (Collapse) | Author | Lines |
|
This is a little tricky, as we only want to walk the modules in each
season's package. The pkgutil module provides a convenient function
called `walk_packages` which can walk recursively, but this isn't
desirable as not all modules are cogs - for example, the modules nested
under `evergreen.snakes` are only helpers, and the `setup` function is
instead present in the package's `__init__.py`.
As we no longer have modules directly in the seasons package, we can
remove the `ispkg` check.
|
|
|
|
Defining seasons in seasonal packages' __init__.py files made more
sense when extensions were strictly tied to seasons. It introduces an
annoying circular dependency where a seasonal package must be imported
in order for the __init__.py file to run and register the season, but
it also imports SeasonBase from the parent directory so that it can
inherit from it.
I have made the decision to scrap the seasonal __init__.py files, and
instead define all seasons directly under SeasonBase. The classes are
no longer scattered around, we remove the above mentioned import
problem, and everything is more transparent and easier to digest.
|
|
|
|
Co-Authored-By: Karlis S. <[email protected]>
|
|
This improves both the visual embed, and the code used to generate it.
We'll now only display active months if the current season isn't the
evergreen - no reason to list the 12 months. The season's name and
avatar will be shown in the author field, as this is more less
aggressive and more visually pleasing than using title + thumbnail.
The embed will be coloured using the season's colour attr.
All values have safe fall-backs for situations where the seasonal
assets have failed to load.
|
|
We no longer use the class docstrings for announcements, and they
mostly contain outdated information. Sentences still relevant are
used to populate the `description` attr (which shows in the branding
embed), the rest is scrapped.
The descriptions themselves can still be improved in the future, once
we figure out exactly in which direction we want to go with them.
The idea of providing a description for each season's branding was
originally brought up by neonsea, co-authored below.
Co-authored-by: Rasmus Moorats <[email protected]>
|
|
We'll use this to colour the branding embed, as it currently looks very
plain. Seasons can either provide their own, or just use the default
green.
|
|
It is not critical that a token is provided, as the target repository
is public. However, if a token is provided, let's use it.
|
|
|
|
We're now presenting a lot more information (paths vs only filenames
previously), so visually this works better.
|
|
A few extra words about the look-ups being able to fall back on safe
values. The comments also introduce extra visual separation between
logical steps in the process.
|
|
Previously we were showing the entire queue of coming-up icons. As we're
now showing full paths (rather than just filenames), this creates a lot
of visual clutter that is unnecessary. It's not critical to know in
which order the icons will be cycled, as there's no way for us to affect
it anyway. This list of all available icons is still displayed above.
The information about configured cycle frequency goes in the footer,
if we're cycling.
|
|
There is an annoying collision in the "server icon" vs "bot icon"
nomenclature, so I made the decision to always refer to the bot's image
as avatar. This choice is already visible through the module, we only
need to adjust the actual filename that we're looking for.
The filenames will be adjusted in the branding repository.
|
|
Less error-prone; easier to adjust.
|
|
The previous implementation would simply ignore assets not present in
the current season's directory.
On the condition that at least one asset is missing, and the current
season is not the evergreen, we also poll the evergreen directory,
and use it as fallback.
This behaviour is shielded such that we only make the extra API call if
there is a missing asset, i.e. if there is something to be gained.
|
|
Since the banner and avatar assets will always have the same filename,
we need their full paths to differentiate between assets of different
seasons. Rather than introducing more complexity to the `pretty_files`
function and deconstructing the download urls, we can just store the
path as provided by the API.
We also now print the `path` instead of showing bools in the status
embed, as just the fact that there is some banner is not enough
information - we want to know which season's banner has been picked
up during refresh.
|
|
We do not have any multi-word seasons at the moment, but there is no
reason to restrict the command to just one word.
|
|
|
|
Asyncio's sleep will accept both, and we default to an int, so might
as well not break our own promise.
|
|
Importing the bot instance will allow us to safely access
the `wait_until_ready` method without having to make fragile
assumptions about the arguments passed to the decorated method.
Although still not perfect, this feels a lot cleaner and safer than
the previous approach.
|
|
It makes more sense for it to be positioned alongside other core bot
features.
|
|
|
|
See docstring for implementation details.
|
|
We want to prevent listeners from performing season-specific behaviour
outside of specific months.
|
|
A guarded listener will abort if the triggering event happens outside
of `allowed_months`. This provides a convenient way of season-locking
listeners without having to write guards directly within their bodies.
|
|
Raise a custom exception if the command fails. This is then handled
in the error handler, and the user will be informed of which months
allow the invoked command.
|
|
|
|
|
|
Prevent re-applying branding if the user requests an already active
season. This saves us an expensive operation.
Only trigger typing if season switch was successful and `apply` will
be called, as otherwise the bot will respond immediately.
|