[bot] Branch vivek/jump\-url\-infr\-log was force-pushed to `c6af8bf`
#dev-log
1 messages ยท Page 8 of 1
GitHub Actions run 4167932058 succeeded.
2fa1915 Bump coverage from 7.0.1 to 7.0.5 - dependabot[bot]
9a4922e Merge pull request #834 from python-discord/dep... - Xithrius
411c8c4 Bump httpx from 0.23.1 to 0.23.3 - dependabot[bot]
ce5d448 Merge pull request #830 from python-discord/dep... - Xithrius
3954572 Bump django from 4.1.4 to 4.1.5 - dependabot[bot]
GitHub Actions run 4167997834 succeeded.
Could you clarify, I don't really follow. Where would the on-error go, and what is the second step. Why does it matter knowing which fails, don't we just care that we run this step if something fails?
9734327 Add legacy help access to self-assignable roles - mbaruh
[python-discord/bot] New branch created: legacy\_role
Also the reactions on the embed needs to be changed to buttons right?

Puts viewing permission of the legacy help channels behind a role that can be self-assigned.
GitHub Actions run 4168057345 succeeded.
Simple as the title says really; this is the domain the tutorial lives at now.
GitHub Actions run 4168875447 succeeded.
Thanks, it looks like there are a couple of other occurences of the old domain (https://github.com/search?q=repo%3Apython-discord%2Fsite vcokltfre.dev&type=code), could you update them too?
[python-discord/bot] branch deleted: legacy\_role
Issues are for reporting problems or requesting features or changes to the bot.
Connected!
GitHub Actions run 4168940386 succeeded.
Thanks, it looks like there are a couple of other occurences of the old domain (https://github.com/search?q=repo%3Apython-discord%2Fsite vcokltfre.dev&type=code), could you update them too?
:ok_hand: all done
GitHub Actions run 4168946032 succeeded.
[python-discord/bot] New comment on pull request #2374: Make the infraction message mention @ModMail
For whatever this is worth: I just tested this in my test server by warning a dummy account that hasn't viewed the main guild in a long time, and the ModMail bot was not in that account's user cache until I clicked through to the guild.
Ah interesting, it probably is good that we mention it's the modmail bot then ๐
[python-discord/bot] branch deleted: swfarnsworth\-modmail\-account\-mention
GitHub Actions run 4168961567 succeeded.
Connected!
Sorry for not noticing your message earlier @bj0key, I assigned it to someone else, hope you don't mind.
Like the msg += f"\n{Emojis.failed_file} {blocked_msg}"?
fa2cd5c Add has_output and has_files for EvalResult - ionite34
Added the has_files property to EvalResult so now looks like
# Skip output if it's empty and there are file uploads
if result.stdout or not result.has_files:
msg += f"\n```\n{output}\n```"
GitHub Actions run 4170020817 succeeded.
We would still need the successful files though, or else we don't know which of the files in result.files is safe to send. If we accept strings we'd return a string as well, and then we'd need to iterate once more for each result.files to check if the path is in the blocked files, and risk any Path normalization mismatch, as well as needing to use pathlib / os to get the suffixes of string paths to display as errors.
I've attempted generalizing this but it feels more complex and mor...
GitHub Actions run 4170924214 succeeded.
bot/issues/2382
Just needed to change ctx.send to ctx.reply and remove the author.mention.
GitHub Actions run 4172733864 failed.
GitHub Actions run 4173066580 succeeded.
GitHub Actions run 4174016338 failed.
GitHub Actions run 4174033529 failed.
GitHub Actions run 4174072920 failed.
GitHub Actions run 4174089792 failed.
bot/issues/2382
Just needed to change ctx.send to ctx.reply and remove the author.mention.
What if the response gets redirected to a different channel? @redirect_output() doesn't change the behavior of ctx.reply() so the result won't be redirected when it should.
It may be worth considering having @redirect_output() add an extra bool attribute (maybe redirected?) for whether or not the output was redirected or maybe even replacing the ctx.reply() function to send a mess...
bot/issues/2382
Just needed to change ctx.send to ctx.reply and remove the author.mention.What if the response gets redirected to a different channel?
@redirect_output()doesn't change the behavior ofctx.reply()so the result won't be redirected when it should. It may be worth considering having@redirect_output()add an extra bool attribute (mayberedirected?) for whether or not the output was redirected or maybe even replacing thectx.reply()function to send a m...
Connected!
#2394
/tag listlists all the accessible tags/tag getempty `` returns the same output as/tag list- removed the
searchsub-group
Screenshots:


. Making this bump removes the need for a lot of the things to be passed into the with below
The Deploy name here won't be the same on all repos. We should make this an input, or standardise the name across our repos.
How about we go for the standardization option?
Done in a1a6292fb61ee8b6ea54c5a47b43d762fb6944bb
I think setting it as a variable is better, that way we'd avoid having the with statements scattered all over the over workflows that'll call this one.
At worst, we can have it as an input, and default to the variable. But shouldn't be needed in our case
[python-discord/bot] New branch created: test\-workflow
Please ignore this PR, as it serves as a test to reproduce a failing wokrflow
GitHub Actions run 4175595884 failed.
GitHub Actions run 4175606039 succeeded.
1feccea Revert "Merge PR #2400: Reusable status embed w... - shtlrs
[python-discord/bot] New branch created: revert\-2400\-reusable\-status\-embed\-workflow
Reverts python-discord/bot#2400
GitHub Actions run 4178928205 succeeded.
GitHub Actions run 4181043818 succeeded.
This pr aims to test the reusable status embed with a PR from a fork, will be closes shortly
It still failed?
It's supposed to fail, yes.
The PR that introduced this will be reverted today so that everyone's workflows pass until we find a solution.
When !pypi is unable to find a package, an error is sent like so:

However, the trashcan reaction can be used by anyone to delete the message. This can be problematic as it can be intentional to show that a package with that name doesn't exist. I propose that only the user that invoked the command will be able to delete...
The purpose of this PR is to concretize Scale's suggestion to have a bootstrap script that talks to Discord's API, then populate a server environment.
Later on, we will rely on Pydantic to load the config classes based on that newly populated environment file, which we can later use for in out bot.
For simplicity, and only for demo purposes, the previous config classes have been wiped off, and only the roles & channels ones were left, with 2 attributes tops each.
GitHub Actions run 4188495073 succeeded.
As far as I can tell only the invoker and moderators should be able to delete it. It will however always auto-delete after a delay to clean up the channel.
This isn't done with eval because a error is a valid result. We could change it for pypi, but I think most errors would probably be because of a mistake by the person running the command.
GitHub Actions run 4196380477 succeeded.
[site] Branch vivek/add\-jump\-url\-field was force-pushed to `8a95402`
GitHub Actions run 4201208648 succeeded.
GitHub Actions run 4201234441 succeeded.
GitHub Actions run 4201257755 succeeded.
Migration files are not for humans anyway. However, I've gone ahead and generated a new migration file.
@Preocts were you wanting to implement this?
If not, I'd like to do this, so can I please be assigned?
I'd like to have a go at implementing this, so can I please be assigned?
Bumps isort to its latest version
GitHub Actions run 4204341153 succeeded.
[python-discord/bot] branch deleted: revert\-2400\-reusable\-status\-embed\-workflow
GitHub Actions run 4204521630 succeeded.
Connected!
GitHub Actions run 4204545755 succeeded.
GitHub Actions run 4204569776 succeeded.
Connected!
Connected!
GitHub Actions run 4207398509 failed.
GitHub Actions run 4207560760 succeeded.
[python-discord/bot] Checks Successful on PR: #2403 Migrated `!tags` command to slash command `/tag`
GitHub Actions run 4207666470 succeeded.
GitHub Actions run 4207780173 succeeded.
Any thoughts on how the behaviour on mobile could be improved?
It should wrap so the whole thing is to the next line, like I mentioned in the description. Either same line as sub-articles or each one their own line.
At the moment sub-articles seems to be wrapping to fit on the same line as the title. I doubt this works when title is longer (for pages other than the contributing index page) even before adding the edit on github like, so it would probably be best to have them both take ...
typing.Self is 3.11, the bot uses 3.10.
Being able to use | for this operation just seemed nice here ๐
Oh, you mean you want to filter the file names as well? alright.
GitHub Actions run 4211028167 succeeded.
This will have to assume that every antispam filter has an extra setting called interval (holds now, but isn't logically guaranteed), and the attribute being summed is different every time, so you either exclude the fourth line, or send a function to fetch the right value from each message. I'll think about it, but at first glance trying to generalize it seems clumsy.
typing.Selfis 3.11, the bot uses 3.10.
Import it from typing_extensions
seemed nice
Between nicity and simplicity I would surely pick simplicity :)
Fair point. When would you say it would be worth using the dunder then?
Not sure actually. It is pretty nice if you're making some super general data structure, like a set or enum.IntFlag. IMO dunders are useful for writing more complex DSL-like expressions, like foo | (bar & baz - (fizz | buzz)).
Although Clojure programmers are fine without infix notation at all :shrug:
(union foo
(difference
(intersection bar baz)
(union fizz buzz)))
GitHub Actions run 4213502858 succeeded.
GitHub Actions run 4213560483 succeeded.
GitHub Actions run 4216437426 succeeded.
GitHub Actions run 4216532247 succeeded.
Connected!
GitHub Actions run 4216557307 succeeded.
0673563 Make bookmark a guild only command - ChrisLovering
04d3671 Remove text-based bookmark command - ChrisLovering
8632f1d Update docstrings and error messages in Bookmar... - ChrisLovering
e2f1488 Move action_bookmark to inside the ContextMenu ... - ChrisLovering
89583ed Only successfully reply to bookmark if bookmark... - ChrisLovering
[python-discord/sir-lancebot] New branch created: deprecate\-bookmark\-text\-command
I'd like to have a go at implementing this, so can I please be assigned?
Sure, I've assigned you ๐
GitHub Actions run 4216824463 succeeded.
[sir-lancebot] Branch deprecate\-bookmark\-text\-command was force-pushed to `09fdc89`
Description
This deprecates the text-based bookmark command, now that we have the context menu command.
Any users that invoke the old text-based command will be told how to use the new context menu command in sir-lance-playground.
This also simplifies a lot of the implementation of the bookmark cog.
Did you:
- [x] Join the Python Discord Community?
- [x] Read all the comments in this template?
- [x] Ensure there is an issue open, or ...
GitHub Actions run 4216844160 succeeded.
GitHub Actions run 4216849902 succeeded.
GitHub Actions run 4216835799 succeeded.
[sir-lancebot] Branch deprecate\-bookmark\-text\-command was force-pushed to `76dd03a`
[sir-lancebot] Branch deprecate\-bookmark\-text\-command was force-pushed to `3c8f5cc`
Connected!
GitHub Actions run 4216890220 succeeded.
We need to handle the case where the message is deleted before the bot sends the response. Currently an error is raised:

To reproduce, run !e import time;time.sleep(5) and immediately delete your message.
There are three main options I can think of for handling this case:
- Catch the error and send no response
- Catch the error and resend the message with a ping instead o...
I just looked into the @redirect_output() i think it's also sensibile to change those to .reply() as well
You can only reply to messages in the same channel, so if this message gets redirected to another channel (such as bot-commands in this case) the message in bot-commands you can no longer reply to the original message.
I'm currently getting an error when running this if there are too many matches, we should probably trim the results in these cases:
bot-bot-1 | 2023-02-19 15:45:18 | asyncio | ERROR | Task exception was never retrieved
bot-bot-1 | future: <Task finished name='CommandTree-invoker' coro=<CommandTree._from_interaction..wrapper() done, defined at /opt/poetry/cache/virtualenvs/bot-TFcQMFAJ-py3.10/lib/python3.10/site-packages/discord/app_commands/tree.py:1089> exception=HTT...
I don't think any of the syncing code should be necessary, since we do that automatically now (https://github.com/python-discord/bot-core/pull/171)
Could try and make an instance for Interaction like was done with context, although if the tests work as is it's probably fine to just remove this. I can't remember exactly what it does :P
async def get_command(self, interaction: discord.Interaction, *, name: Optional[str]) -> bool:
Looks a bit neater in the command, since it's obvious it's the tag name so no need to repeat tag. (will require updates in the rest of the function ofc)
This sounds fine to me, we can always restrict it again if there's an issue.
I don't really mind, maybe the current behaviour of using usernames is the best balance between letting/not letting people influence the results
This sounds sensible, are you interested in opening a PR @Numerlor?
It was mentioned in #community-meta that it seems very difficult to detect these cases. Also, other suggestions involving deleting people's messages have been rejected since it's quite confusing and means the person will lose their message content.
The tests work fine, so I will just remove the comment
log.warning(f"An antispam filter named {content} was supplied, but no matching implementation found.")
warn is the identical-but-deprecated version of warning
log.warning(f"A filter named {content} was supplied, but no matching implementation found.")
probably neater to just use default literals where possible
def get_message_metadata(self, message_id: int) -> dict | None:
I'm currently getting an error when running this if there are too many matches, we should probably trim the results in these cases:
bot-bot-1 | 2023-02-19 15:45:18 | asyncio | ERROR | Task exception was never retrieved bot-bot-1 | future: <Task finished name='CommandTree-invoker' coro=<CommandTree._from_interaction.<locals>.wrapper() done, defined at /opt/poetry/cache/virtualenvs/bot-TFcQMFAJ-py3.10/lib/python3.10/site-packages/discord/app_commands/tree.py...
This is pretty tight, I can't think of any valid reason it should be longer than this so I guess it's fine though...
Sure, but I'm currently a bit busy so if anyone else is interested they're free to do so.
On 02/19/2023 5:07 PM CET wookie184 @.***> wrote:
This sounds sensible, are you interested in opening a PR @Numerlor https://github.com/Numerlor?
โ
Reply to this email directly, view it on GitHub https://github.com/python-discord/bot/issues/2385#issuecomment-1436027007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGFP55DKX4YTH7JTS42O6HLWYJAKPANCNFS...
The message redirecting the user is about the same size as the information message itself, so I feel it would make more sense to just send the information directly to the channel where it's invoked- it doesn't seem too noisy.
(There's also currently a slightly weird case currently when using the command in sir_lancebot_playground as it sends the info message and then an embed directly below linking to the message above.
I don't think any of the syncing code should be necessary, since we do that automatically now (https://github.com/python-discord/bot-core/pull/171)
@wookie184 should this also be removed?
I think we should try to avoid any cases of "The application did not respond" errors on the client. Another case where this can happen is where no match can be found e.g. /tag get fionferonfero
@wookie184 Should it always return True now as an embed has to be sent either ways or should it return False when no match for a tag is found?
Even after removing this, the bot works fine. So I guess its best to remove it.
[sir-lancebot] Branch deprecate\-bookmark\-text\-command was force-pushed to `5735d23`
Yea I like this suggestion, pushed the change.
GitHub Actions run 4217246285 succeeded.
Currently setting up my development environment
label="Choose a title for your bookmark (optional)",
[sir-lancebot] Branch deprecate\-bookmark\-text\-command was force-pushed to `2ef50af`
Relevant Issues
uncaught typo in #1176
noticed it the very first time I went to use the command.
Description
Did you:
- [x] Join the Python Discord Community?
- [x] Read all the comments in this template?
- [x] Ensure there is an issue open, or link relevant discord discussions?
- [ ] Read and agree to the contributing guidelines?
[sir-lancebot] Branch deprecate\-bookmark\-text\-command was force-pushed to `82535ee`
Connected!
GitHub Actions run 4217782955 succeeded.
GitHub Actions run 4218696741 succeeded.
a41a997 Reverse timeline entries so newest entries come... - ichard26
[python-discord/site] New branch created: flip\-timeline
We agreed internally that this would look better, and especially as I add more entries.
This was automated using this script:
import dataclasses, sys, textwrap
from pathlib import Path
import bs4
@dataclasses.dataclass
class TimelineEntry:
title: str
date: str
html_doc = Path(sys.argv[1]).read_text("utf-8")
soup = bs4.BeautifulSoup(html_doc, "html.parser")
entries = []
for item in soup.find_all(class_="cd-timeline__block"):
entries.append(Ti...
GitHub Actions run 4219648168 succeeded.
This may be easier to review locally with git show as the diff will contain no red or green lines, indicating that the contents weren't changed, only moved.
Had a look at it in netlify and it all looks good.
GitHub Actions run 4225087387 succeeded.
GitHub Actions run 4225435309 succeeded.
Description
on_message function:
https://github.com/python-discord/sir-lancebot/blob/9ecf423268bb3a89e881e4b28e5ee56fe9b33819/bot/exts/utilities/githubinfo.py#L175
https://github.com/python-discord/sir-lancebot/blob/9ecf423268bb3a89e881e4b28e5ee56fe9b33819/bot/exts/utilities/githubinfo.py#L183
Here the on_message function returns more than just issues, it also returns pull requests. So the docstring and the variable names should be changed accordingly.
Possible Solutions
...
https://www.pythondiscord.com/pages/guides/pydis-guides/contributing/sir-lancebot/#environment-variables This fragment of the page displays needed environment variables to run the bot but it is missing an environment variable for the trashcan emoji, which is needed to run the help command. And as the help command is common to test the bot, its essential. Same in this [page](https://www.pythondiscord.com/pages/guides/pydis-guides/contributing/sir-lancebot/env-var-reference/#general-variabl...
[python-discord/sir-lancebot] branch deleted: deprecate\-bookmark\-text\-command
25d863d Make bookmark a guild only command - ChrisLovering
772509c Remove text-based bookmark command - ChrisLovering
4d67d4a Update docstrings and error messages in Bookmar... - ChrisLovering
079e031 Move action_bookmark to inside the ContextMenu ... - ChrisLovering
eac0baf Only successfully reply to bookmark if bookmark... - ChrisLovering
Connected!
GitHub Actions run 4227257264 succeeded.
I believe we should be able to remove this too, yeah, since there's nothing specific to the cog.
We need to be careful to ensure that we don't break normal tag invocation (with just the name of the tag, e.g. !code). This is handled in the error handler here https://github.com/python-discord/bot/blob/main/bot/exts/backend/error_handler.py#L162
For that it makes sense to give no result if a tag wasn't found, although if a user is using the tag get command explicitly I think they should always get a response (e.g. saying "no tag found").
I'm not sure what the best way to make this cha...
From GitHub's API's perspective, pull requests are a type of issue https://docs.github.com/en/rest/issues/issues?apiVersion=2022-11-28#list-issues-assigned-to-the-authenticated-user
Note: GitHub's REST API considers every pull request an issue, but not every issue is a pull request. ...
For user facing (e.g. help command text) I think it's worth listing both, but because this is internal I'm not sure it's worth changing, although maybe it would be more clear, I don't mind.
Sounds like a good idea, I've assigned you
The names of team roles on the server are plural (Admins, Helpers). A reason for this is that it looks better in pings (because when you ping you're pinging multiple people), and also in the member list (because it's a heading for multiple people with the role). I think it would make most sense to be consistent with that.
The codeblock additions sound good.
I don't think the try/except should belong here, but in the can_run function instead.
It should be a simple "yes or no" question, and the CommandError should be handled inside and return False upon that
ctx: Context | discord.Interaction,
this can be done for the rest by ditching the typing import as well, if you want :p
Example: list[str] will work too
I don't think a callable should default to False, should it ?
Is there a reason for removing the aliases ? Or aren't they allowed in app commands?
I think the same issue occurs in bot too, doesn't it ?
Actually, never mind me.
I just realized that this is not part of the lib.
My bad, sorry for that
This might be better served with another application command, similar to how we changed the main bookmark command to one.
We can also deprecate the existing text command that way too.
If we make this delete command a global command, we can remove perms for people to run it in-server so it will only appear in DMs.
For user facing (e.g. help command text) I think it's worth listing both, but because this is internal I'm not sure it's worth changing, although maybe it would be more clear, I don't mind.
@wookie184 When I was trying to find the source of this command I overlooked this file because the docstring mentioned 'issues' in the on_messagefunction, I found the source of this through Chris when he redirected me. So it kinda causes confusion.
I think the same issue occurs in bot too, doesn't it ?
It is explicitly mentioned in config.yml under style.emoji to atleast change the trashcan emoji and style.emoji is mentioned on the python bot contributing page as needed to run the.
The reason for using aliases was for ease of user but now as slash commands display all the commands it would kind of get clustered seeing one command take up all the space in the suggestions pop up, like eg: just writing t will take 6(3 for get, 3 for list) space. Also when just typing the user can see the commands and can now, even autofill the subgroup easily. And this is the reason discord has removed support for aliases for slash commands.
we can remove perms for people to run it in-server so it will only appear in DMs.
Humm I see, just like the perms issue that happened for some people with the new bookmark command? That's a good idea.
we can remove perms for people to run it in-server so it will only appear in DMs.
Humm I see, just like the perms issue that happened for some people with the new bookmark command? That's a good idea.
At a per command level you can control what users have permission to run it

That's neat.
Alright, sounds pretty good!
That's neat.
Alright, sounds pretty good!
You can set it in-app using this
Setting an empty permissions field will disallow anyone except server administrators from using the command in a guild.
I think it gets my question unanswered, my question was that earlier the tag text command function returned False when no embed was sent but as of now the tag slash command sends an embed either way(if the tag was found and if the tag wasn't found). So, should the function now return True if an embed is sent for no tag found or should it return False when a tag is not found.
Also about the error handler, I have already made changes to it i.e migrated it to handle slash command, th...
GitHub Actions run 4234343314 succeeded.
I'm not sure if the intention of this issue is to replace the direct invocation of tags (e.g. through !code), or just the actual !tag command.
I think replacing the actual !tag command makes sense, but not removing the direct invocation. It does not seem like an improvement to go from !code to /tag get code, pressing enter, then having to press enter again after it autocompletes to /tag get codeblock, all with a bunch of discord UI popping up in the process. Having /tag with ...
Tested out and all looks good. Aside from the setup installation change we discussed, I think this is good to go. Feel free to merge when ready.
5b5f21f Only install python3-pip on control as it i... - GDWR
I completely agree with what wookie said, I asked in the discord server but was advised it is a full migration.
Also @wookie184 your review comments makes sense now, sorry for misunderstanding.
[python-discord/site] Pull request opened: #882 Contributing Page\->Sir Lancebot: update description
Closes #880 and #881
- Removes typo for the
Adminsrole being speltAdmin - Added the
TRASHCAN_EMOJIas needed - Added code blocks for channel names
GitHub Actions run 4237378942 succeeded.
GitHub Actions run 4241190630 succeeded.
You can ditch the static method and use lambdas instead
tags_get_command.can_run = can_run if can_run else lambda interaction: False
Use the callback property of the app_command to invoke the tag command.
Change this to get the actual tag command as self.bot.get_command doesn't returns app_commands
Also wookie the !code is already broken as the tag command now uses discord.Interaction and the ctx captured with the message containing !code has its interaction attribute return None, which means the tag command can't be invoked. A possible work around for this would be to have get_command_ctx in tags.py and try_get_tag_ctx in error_handler.py or we have to make the get_command ugly by doing isinstance everywhere.
[python-discord/infra] New branch created: pin\-linting
Pin dependency versions, and add dependabot to alert DevOps org role weekly of new dependencies.
921f581 Pin dependencies & resolve ansible-lint failure... - GDWR
[python-discord/infra] branch deleted: pin\-linting
There are some params that could be removed thanks to the new version IIRC, we might as well do that
[python-discord/infra] branch deleted: GDWR/local\-testing
Doesn't one \n mean there are two lines?
And then continuing the previous comment this line also won't be necessary.
This budget is shared with the stdout.
Same here, the number of lines added is the count + 1
Not a big deal, but I think it would be nicer if format_output would take a placeholder string if the output is empty, instead of the mark_no_output flag.
I'm also in favor of what wookie said. Seems like a downgrade to remove to !tag functionality. Ideally the slash command would increase visibility
Yeah let's keep the direct usage for now.
More precisely, this should strip newlines since they won't be displayed in the message.
(sorry i'm sure you know this already, I just wanted to summarise to ensure we're on the same page).
The error handler is used as the individual tag names aren't registered as commands (e.g. !code), so we catch any CommandNotFound errors, and in those cases try and match the name given to a tag (this also allows us to do fuzzy matching that doesn't interfere with other tags).
Currently the !tag get <name> command, and direct !<name> invocation are pretty much exactly the same and ...
Finally we are on the same page๐๐ฝ
dc7653b Refactor format_output to have output_default... - ionite34
Refactored to output_default str in dc7653b
Refactored to output_default str in dc7653b
GitHub Actions run 4246765765 succeeded.
GitHub Actions run 4246793460 succeeded.
Fixed in 7e7f7c3
- Now uses count of
\n+ 1, and usesformat_textwhich will have already been striped byformat_output
- budget_lines -= file_text.count("\n")
+ budget_lines -= format_text.count("\n") + 1
GitHub Actions run 4246816055 succeeded.
GitHub Actions run 4246898160 succeeded.
Not need this now as we are bringing back normal invocation through ctx.
GitHub Actions run 4247087050 succeeded.
[python-discord/bot] Checks Successful on PR: #2403 Migrated `!tags` command to slash command `/tag`
GitHub Actions run 4247598605 succeeded.
We need to handle the case where the message is deleted before the bot sends the response. Currently an error is raised:
To reproduce, run
!e import time;time.sleep(5)and immediately delete your message.There are three main options I can think of for handling this case:
- Catch the error and send no response
- Catch the error and resend the message with a pi...
f"/proc/{getpid()}/fd/*" isn't available, which I think is a bit too harsh of a sandboxing measure in this case. I don't know of any use case where accessing /proc/{getpid()}/ could be abused. I understand not letting it mess with other processes, but you can restrict it to only its own process using symlinks or something similar, so that shouldn't be much of an issue.
Let me know if that idea sounds good! If it does I'll probably submit a PR within the next week or so to implement t...
ec39c08 holidayreact: add alternate spellings to february - shenanigansd
[python-discord/sir-lancebot] New branch created: shenanigansd\-patch\-1
Relevant Issues
Needs to match love, loves, lovelies, wuv, wuvs... quick, get Shenan in here.
- @Preocts, #python-discussion message
Description
Added alternate spellings and misspellings to the February triggers in the holidayreact cog.
Did you:
- [x] Join the Python Discord Community?
- [x] Read all the comments in this template?
- [x] Ensure there is an issue open,...
GitHub Actions run 4249278959 succeeded.
As I've been implemented in this, I present for consideration:
https://regex101.com/r/1hw10r/1
Original (with plural hearts):
\b(love(s|lie|lies)?|wuv(s|lie|lies)?|hearts?)\b
Simplified (no uwu)
\b(l(ove|uv)(s|lies?)?|hearts?)\b
Simplified (with basic uwu because fun)
\b((l|w)(ove|uv)(s|lies?)?|hearts?)\b
test set:
love
lovelies
luv
luve
wuve, what is wuv?
baby don't hurt me
loves
lovelies
lovelie
wuvlie
wuvlies
wu...
GitHub Actions run 4251562492 succeeded.
An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space.
Should be changed to
sorted_list = unsorted_list.sort() # This will be None
[python-discord/bot] Checks Successful on PR: #2403 Migrated `!tags` command to slash command `/tag`
GitHub Actions run 4251719375 succeeded.
Looks good overall. Some design nitpicks I would like addresed though.
Please call raise_for_error here. You don't need to handle the error necessarily, but it should make it clearer what the issue is if an error is encountered. Same goes for other requests.
Please formally add this to the pyproject, it is currently a transient dependency. We typically use httpx, but they are drop in replacements so it doesn't really matter.
I don't believe this is valid, it appears to be missing the discussed implementation. Currently, on first run this will use the production server's default values, not the ones stored in all_channels.
A lot of the variables here have quite wordy/redundant configurations. For instance, this one uses a field simply to modify the case of the env key (pydantic has a setting to disable case sensitivity, which I believe is the default). This line should just be debug: str = "true", or possibly even debug = True and let pydantic handle the type-coercesion, and infer the type.
You can just leave these as .env and .env.server without trying to resolve the correct location. This project can not be run from anywhere other than the root directory, and that is not intended to change.
If I'm not mistaken, Session doesn't offer a base url feature, I'll extend the Session class to alter the url upon each request
Will do, however we wouldn't want to do that for get_webhook since we need to return the empty object for us to know that it doesn't exist. Or just catch it there
I believe you are correct, hence the recommendation for httpx. Itโs generally more powerful
That sounds fine (side note: should we return a more-explicit null?)
I actually was planning on making it a predicate, so basically a yes or no question to whether the webhook is there or not
Done in 887e88e4f4c6bcde3dbe1e956d549a01fb669820 and 8408f4dd4824ceb6c8902bc613e60462eb13d78f
Done here 42741ef1f41bba8ad534b23b8f4cb5b2076b83d8
GitHub Actions run 4255654336 succeeded.
Done here 0c9cd82016ee9b67f02d12f8874cfd33fdc74570
GitHub Actions run 4255790236 succeeded.
Updated in e5cfc9e2c7378cc5041865dc877e1f15115edc7f
GitHub Actions run 4255827743 succeeded.
That's what I did in the first place, but flake8 didn't like that.
Here's what it says
B008 Do not perform function calls in argument defaults. The call is performed only once at function definition time. All calls to your function will reuse the result of that definition-time fun
ction call. If this is intended, assign the function call to a module-level variable and use that variable as a default value.
Which is why I did that, I can either leave it the way it is or t...
There's an issue with this transformation being conditional. If lines_nums is False, output stays a string, and then "\n".join(output) a few lines later breaks it into one character per line.
That's not actually it. This is there to ensure backwards compatibility with the env variables that might be in production.
The values are not the same, as you can see here we don't define a prefix for this specific class, unlike the rest where it's usually something__
Since in the old setting this was extracted from a pure env variable called BOT_DEBUG, I thought I'd leave it the way it is.
But if we were to change it, we need to make sure that we define them in the prod config as wel...
That's true, my bad.
I had changed it before & then I wanted to experiment further with something else.
Fixed here 97a5d864e597441cd7f19c8e2dc53d919af64448
GitHub Actions run 4257165110 succeeded.
Well, I ended up making it a module level var here db665dcd1ccdd89ff4bd1c20bfb3c340418c86c3
GitHub Actions run 4257204718 succeeded.
Done in 5ee1bfd5006ffd63e220de72c971a279916f18fe
Do you want to resolve this and keep discussing it in https://github.com/python-discord/bot/pull/2408#discussion_r1116254111 ?
GitHub Actions run 4257233608 succeeded.
Doc item doc_item.symbol_id='csv.csvreader.fieldnames' present in loaded documentation inventories not found on site, inventories may need to be refreshed.
GitHub Actions run 4261253978 was cancelled.
GitHub Actions run 4261260455 was cancelled.
GitHub Actions run 4261267564 succeeded.
[python-discord/sir-lancebot] Checks Successful on PR: #1216 Bump python-dotenv from 0.21.1 to 1.0.0
GitHub Actions run 4261764414 succeeded.
Create a tag that explains how double-clicking a Python (.py) file spawns an instance of the user's shell that terminates when the process finishes.
It should explain to the user how to open the shell, cd to their directory (or right-click and "open PowerShell here"), and use python (or py) to run their file and see the results.
Create a tag explaining that users need to open their shell to execute binaries, namely pip; that you can't execute them from within a Python script/REPL.
Create a tag that summarizes the difference between the shell and the REPL, what each one is used for, and how to "escape" the REPL to get back to the shell.
I created a token but I get this message for /pixels and other routes. What does this message mean? How use POST request to /authenticate?
{
"message": "The token provided is not the access token, make a POST request to /authenticate. Refer to the documentation for more information."
}
3d19133 Fix and simplify logic for optional line numbering - ionite34
GitHub Actions run 4265857263 failed.
GitHub Actions run 4265903659 succeeded.
[python-discord/forms-backend] Checks Successful on PR: #238 Bump python-dotenv from 0.20.0 to 1.0.0
GitHub Actions run 4266297109 succeeded.
GitHub Actions run 4267059722 succeeded.
GitHub Actions run 4267093483 succeeded.
This PR needs to be merged with bot#2408
We're currently migrating our entire configuration to rely on Pydantic models in order to represent all of our needed constants.
This removes the YAML configuration files entirely and relies on .env files to store the values of these constants & map them to our constant classes.
This updates the contribution guide to:
- Explain how can contribs generate a server config using the serve...
GitHub Actions run 4267234080 failed.
GitHub Actions run 4267326284 succeeded.
GitHub Actions run 4267418102 failed.
Could you move the previous topics as part of the description instead? I feel like it might be too distracting to be in all bold and big like that
The comment seems wrong and unnecessary. It is wrong because the comment talks about the embed as a whole, while we are operating on embed's title. It is unnecessary because it can be inferred from the code that we reassign the embed.title if it exceeds the title character limit
@Anonymous4045 Also resolve this, by implementing it.
I think this should be made a new section as this marks the beginning of the old manual method.
Same here, this will look better.
**Note**: The `.env` file will be ignored by commits.
Looking at the static deploy this currently looks ugly. This would be much better.
**Note**: This phase can be skipped and done manually, but would require extra manual work.
The structure you see is not final, which
Is why the PR is a draft, since it's not ready to be reviewed.
I only made it so I can see the changes I have made clearly.
Thanks for the suggestion though, i will definitely keep it in mind! :)
Why send a string instead of a path object?
What if the files changed?
GitHub Actions run 4269731896 succeeded.
GitHub Actions run 4269789617 succeeded.
GitHub Actions run 4269826304 succeeded.
GitHub Actions run 4269862412 succeeded.
GitHub Actions run 4269871043 succeeded.
GitHub Actions run 4269886734 succeeded.
GitHub Actions run 4269909610 succeeded.
GitHub Actions run 4269917717 succeeded.
GitHub Actions run 4269926153 succeeded.
GitHub Actions run 4269940511 succeeded.
GitHub Actions run 4269970614 succeeded.
71d8d5b Fix timeit commands with backticks after comman... - wookie184
[python-discord/bot] New branch created: timeit\-backticks
In theory the list of allowed commands shouldn't be necessary, but I'd prefer to keep it to make the functionality more robust.
GitHub Actions run 4270144919 succeeded.
Didn't test this, but it doesn't look like the changes will break anything.
Other than that, LGTM !
Looking good, thanks!
I wonder whether it would be better to just have a /tag command, since currently /tag get with no arguments is the same as /tag list, so i'm not sure there's any point in having two commands. One would be shorter to type and simplify the code a little.
I don't think there's any point in having the custom _can_run if it doesn't run any checks. I think we should either just run the global checks manually using the (undocumented) self.bot.can_run, or run the checks for the interaction get command (they should both do the same thing since the interaction get command doesn't add any custom checks).
The main useful global check is the one to ensure we're on the guild, there's also one to ensure the command isn't invoked by a bot - i'm not ...
a85401f Bump pre-commit from 3.0.4 to 3.1.0 (#1215) - dependabot[bot]
[python-discord/sir-lancebot] Checks Successful on PR: #1216 Bump python-dotenv from 0.21.1 to 1.0.0
GitHub Actions run 4270796469 succeeded.
Connected!
GitHub Actions run 4270797636 succeeded.
| `TRASHCAN_EMOJI` | The full emoji to use for the trashcan, for example, `:wastebasket:` |
It might be worth mentioning a good default value, so people don't need to think about what to put.
Closing this as I don't think there's anything that should be changed.
Closing as I don't think this is feasible or something we really want.
I wonder whether it would be better to just have a
/tag <name>command, since currently/tag getwith no arguments is the same as/tag list, so i'm not sure there's any point in having two commands. One would be shorter to type and simplify the code a little.
I had a conversation about this on discord with @ChrisLovering, he suggested these making the commands like that.
I think if the emoji is deafult on discord it needs its unicode and if it is a custom made emoji it needs its id. The output of sending \:emoji: just returns what is needed.
So shall I still change it?
Could you clarify this change? This would not have the correct value in production and require overriding. I prefer to remain consistent and just have prod values, and require devs override.
I've accepted the upfront migration as a cost of the upgrade. We should not add confusion/maintenance cost to avoid 10 minutes of manual work. This also applies to nearly every single Field in this file.
I don't think we should have this guard. This file should in theory not be imported anywhere, and it adds an unnecessary layer of indentation.
removed in 469d609ce53a3e7e1378672c4787cc80444450ba
GitHub Actions run 4271170777 succeeded.
I'm not sure I understand what you mean by this
Are you talking about the name of the class itself and having its own prefix ?
Or are you talking about passing the env kwarg to specify how to fetch it from env variables ?
Or none of the above ?
@HassanAbouelela I'm not sure I understand what you mean by this
Are you talking about the name of the class itself and having its own prefix ?
Or are you talking about passing the env kwarg to specify how to fetch it from env variables ?
Or none of the above ?
Reverted in 686590c0d797aea28d79d94ea939277f734f404d
I got confused & misunderstood something while I was updating the docs. I think my brains got mangled with all of the renaming of the configs & I ticked in my head that we were constructing the site_api in that fashion.
My bad..
GitHub Actions run 4271195213 succeeded.
I'm referring to creating Fields and overriding pydantic's default env key creation. I.e, in the line commented on, the diff would be:
- debug: str = Field(env="BOT_DEBUG", default="true")
+ debug = True
And in prod we'll update the BOT_DEBUG key to whatever pydantic resolved it as.
Ah, I didn't realise that, I don't think the current proposed text is that clear as it's not clear that it means the output when pasted into discord. We could just mention that they could set it to ๐๏ธ (use the unicode char directly).
It would be sort of nice to have something on sir-lancebot's side that made it use that by default in development, so users don't need to set it at all (fwiw the reason we have a custom on on the server is just that it looks nicer).
Alright I will make the test more clear and make a pr on sir-lancebot repo for a default trash emoji
I'm going to close this PR for now as it's been stalled for a while, hopefully it can be reused at some point in the future.
GitHub Actions run 4271300415 succeeded.
GitHub Actions run 4271343315 succeeded.
I'm referring to creating Fields and overriding pydantic's default env key creation. I.e, in the line commented on, the diff would be:
- debug: str = Field(env="BOT_DEBUG", default="true") + debug = TrueAnd in prod we'll update the
BOT_DEBUGkey to whatever pydantic resolved it as.
The confusion happened due to the lack of knowledge that we were ready to update the env var keys in prod as well.
Done in 36ebda1d54cb88033e4be2ef399668f0c3664a15
GitHub Actions run 4271364990 succeeded.
We still want to use the custom one on the server, so this would require setting the env variable in production.
An alternative approach would be to use the Client.debug constant, which defaults to true, but is set to false in production. If this is true we would use the unicode default if the env var wasn't set (this wouldn't require any changes to production environment variables)
Do @python-discord/devops have a preference?
GitHub Actions run 4271378556 succeeded.
An alternative approach would be to use the
Client.debugconstant, which defaults to true, but is set to false in production. If this is true we would use the unicode default if the env var wasn't set (this wouldn't require any changes to production environment variables)
I don't see Client.debug being false anywhere, if anything, we need to set it false by ourselves. Am I right? Or does this happen outside constants.py
The BOT_DEBUG environment variable is set in production, production environment variables can only be set by a member of the devops team. Since it's already set that's why I suggested using it to determine what default to use for the reaction (keeping the reaction production constant here also makes it easier to change in the future if necessary).
GitHub Actions run 4271430022 succeeded.
trashcan = environ.get(
"TRASHCAN_EMOJI",
f"\N{WASTEBASKET}" if Client.debug else "",
)
Normally an if would probably be nicer, but here ideally we should avoid any extra variables being left over in the namespace so people don't accidentally use them in code or get confused. (alternatively we could prefix the default with a _ and del it afterwards)
GitHub Actions run 4271526355 failed.
Sorry, I forgot that isn't a f-string thing, can just remove the f, my bad ๐
Hmm wait i'm not even sure if it's working without, let me try it
Hmm wait i'm not even sure if it's working without, let me try it
okay, I will be waiting.
Hmm wait i'm not even sure if it's working without, let me try it
okay, I will be waiting.
Never mind, just fixing the lint error should be fine. I just had BOT_DEBUG=false in my .env for some reason.
GitHub Actions run 4271565028 succeeded.
I'm not sure this is worth doing. It would be hard to get people to consistently use the tag, and I don't think the forum search feature is good enough to make searching for a question that easy anyway.
Yeah after a second thought, it's not.
I'll close this
3686f60 add the roles channel to the config - shtlrs
5795140 add the AllSelfAssignableRolesView and its corr... - shtlrs
6ab9f9c add the logic for attaching the persistent view - shtlrs
b25ad80 add assignable_roles as a property to the Claim... - shtlrs
1d60403 add implementation of the button's callback tha... - shtlrs
GitHub Actions run 4271644697 succeeded.
@wookie184 is the new description good enough?
Hello,
I'd be interested in working on this issue.
GitHub Actions run 4272482936 succeeded.
GitHub Actions run 4272487827 succeeded.
GitHub Actions run 4272498048 succeeded.
GitHub Actions run 4272510055 succeeded.
Looks fine to me, don't see anything that could break.
Wilder and Kutiekatj9 have been caught abusing the software already to victimize people and talk smack about the people they just victimized in a pattern. They've done this before to anyone they assume to be retarded and if discredited enough people will just disbelieve said retarded individual.
@ForkInABlender this repository is for discussing the development of the bot. If you have an issue with other users you're welcome to write to Modmail.
Hello, I'd be interested in working on this issue. The first problem seems easy to fix. However, I am not sure yet if I can solve the second problem, but I would like to try.
Sounds good, i'll assign you to the issue. If you're not sure about the second issue it's fine to just open a PR for the first.
[python-discord/bot] Checks Successful on PR: #2403 Migrated `!tags` command to slash command `/tag`
GitHub Actions run 4274930259 succeeded.
self.cog.try_run_fixed_codeblock is not used in the test and even after removing it the tests run fine.
Although I do understand that it is used in self.cog.on_command_error but even after removing it the tests run fine, so is it really necessary to have this?
Relevant Issues
Closes #1170
Description
The issue mentioned two problems:
-
interactions edit the message but still show as failed
The problem is that discord automatically says the interaction failed if the bot doesn't respond to the interaction. Adding interaction.response.defer() fixes this. (See this stackoverflow discussion: https://stackoverflow.com/questions/71177867/discord-py-error-message-this-interaction-failed) -
The same challenge seems to be shown every t...
GitHub Actions run 4275013993 succeeded.
I guess it still works because it would hit the line if new_ctx.command is None: which would probably be True. I think it makes sense to leave it though, since this test isn't meant to test that command so it makes the test more contained.
Another alternative would be to make it so try_run_fixed_codeblock is actually tested with both True and False, but I don't think it's worth it, since the test is already pretty complicated compared to the very simple code that it's actually testing.
Just a few nitpicks, other than that, it looks good !
I think this can be kept to Member
Since the invoker needs to be a member of our server if they want to execute the command, so it won't resolve to an instance of User
Nitpick:
tag_name = ctx.invoked_with
It's better this way IMO, and then you can check whether it exists or not like you'e doing in the following line.
The type union comment should also apply here & everywhere else
I think this can boil down to
if not restrict_to_user:
restrict_to_user = getattr(ctx, "user", ctx.author)
The following line only checks that it's not None (which should always be the case, but there's no harm in a check and it makes it so the type is correct later). It still might not be a tag name throughout it's usage, since this is run for all failed commands.
Ahein, I though the maybe prefix was then validated by the following line, The name is still bugging me a bit though :p
I don't think that would work as Interaction doesn't have an author, so it would raise an error (as all the function arguments are evaluated before the function is called)
Ho, you're actually right.
The way it works didn't actually match my thoughts, sorry for that
52fc242 Add default unicode emoji for trashcan (#1217) - Ibrahim2750mi
Connected!
GitHub Actions run 4275342721 succeeded.
Yeah, looks good! We can probably remove it from the requirement vars now that the lancebot PR is merged though.
[python-discord/bot] branch deleted: timeit\-backticks
What was the reason behind using an empty string here, rather than making it nullable?
Connected!
I mean it would be just copying the docstring of get_command and also I have seen these types of docstring referring to other method for more info in the codebase, some examples are in helpers.py. So I think that answers the why and I have already included the where it will be used.
So shall I still change it?
GitHub Actions run 4275387359 succeeded.
Either something has a jump link or it doesn't, storing a string in here too means we can't have a validator on the db that it's a valid link.
IMO we should have a validator on site that requires it to be formatted as a link, or null.
This would be simplified if we went with the "it's either a link or null"
I could be misremembering but Ive read somewhere (django docs or stackoverflow) that using blank strings is recommended by django ORM. I can look for the link later.
And regarding the validator, I could use URLField instead of CharField because it has URL validation.
26783af Add line about the pastebin. - swfarnsworth
[python-discord/bot] New branch created: swfarnsworth\-code\-command\-paste
A URLField that can be blank/null sounds good to me
Something I've observed a lot is people running the !code command to tell users about markdown blocks, only for them to immediately reply saying "my code is too long". This PR adds a new line to the !code tag telling users about the pastebin.
For the sake of brevity, the added line says nothing about how to use the pastebin. If this PR is merged, and users who attempt to use the pastebin after seeing this tag end up finding it confusing, we can revisit the content of this tag.
![ima...
This branch is now incompatible with main, so I'll re-implement the changes in a new branch and open a new PR.
GitHub Actions run 4275518301 succeeded.
Seems sensible, i'd say this can close https://github.com/python-discord/meta/issues/115 too.
GitHub Actions run 4275535816 succeeded.
Connected!
GitHub Actions run 4275571241 succeeded.
[python-discord/bot] New branch created: 2302\-activity\-in\-reviews
Closes #2302
- Only posts review for users who have been active in the past 7 days
- Remove users who have been inactive in the past 30 days from the talent pool
- Make the tp list command sort based on when the review will actually happen, and display
- Send a message in nomination-discussion if a user is automatically removed from the talentpool.
It's not thoroughly tested yet and I will do some more, although I think it's good enough to open and get reviews.
GitHub Actions run 4276252901 succeeded.
I don't think that would work as
Interactiondoesn't have an author, so it would raise an error (as all the function arguments are evaluated before the function is called)
if not restrict_to_user:
restrict_to_user = getattr(ctx, "user", None) or ctx.author
not the best but it would work with shtlrs idea.
Can we undeprecate the text command? The context menu/app command seems to inexplicably disappear from clients for some users, and when it does work, it also has the limitation of not working in read-only channels. I also think the original UX of the original .bm command was pretty nice, especially when replying to messages.
Relevant PR: #1211
I agree with Arl's suggestion to make this a slash command rather than text. [](#dev-contrib message)
and when it does work, it also has the limitation of not working in read-only channels.
Either way, you wouldn't be able to bookmark messages in read-only channels because you can't send text/slash commands there anyway.
and when it does work, it also has the limitation of not working in read-only channels.
Either way, you wouldn't be able to bookmark messages in read-only channels because you can't send text/slash commands there anyway.
the original text command would take any link as input. there is no way to provide input with a link in the current form.
Could you move the previous topics as part of the description instead? I feel like it might be too distracting to be in all bold and big like that
We could do that, but there's a few things to work out first. What would the title in bold be? And what would we set the limit for the topics to show as, since we wouldn't be bound by the title character limit?
@Ibrahim2750mi I thought we were going with preserving the order that the topics appeared in, so people could reference them by number and not have that number change
But that will not allow any new topics to be shown in the embed. Therefore as Chris said the new topics should be added on the number 1 position and oldest topic should be at number 5.
@Ibrahim2750mi I'm not sure I get what you mean. New topics are currently added to the end of the embed's title in a way in which their number doesn't change, so if it says something like "2. How did you start Python?" the number 2 won't change after a third topic is added. If that's not what you meant, could you explain a bit more?
If the embed's title exceed the character limit you directly use the previous_topic which means that it would not append any new topics, so it will stay stuck at those already present topics no matter how many times it is called, because your function just returns the previous_topic when it has reached the character limit. Eg: assume this has exceeded the character limit
1. How to do python
2. How to not do python
3. beep boop
Now even if your function is called it would just retu...
That's certainly an option, but that would change the order of each topic, which could cause some confusion for people unaware of how it works or with responding to a particular prompt. At the moment, the reaction disappears once the limit is reached to dissuade people from trying to get too many prompts. The reason being that someone in the chat should have something to say about one of the four or so prompts.
I think we're also considering moving the topics from the embed title into the m...
GitHub Actions run 4279378700 succeeded.
GitHub Actions run 4279385076 succeeded.
GitHub Actions run 4279390420 succeeded.
GitHub Actions run 4279484877 succeeded.
@shtlrs is it ok, if I resolve this now?
Anyways updated the docstring, kindly have a look.
[python-discord/bot] Checks Successful on PR: #2403 Migrated `!tags` command to slash command `/tag`
GitHub Actions run 4281975879 succeeded.
I agree with Arl's suggestion to make this a slash command rather than text. [Discord Link](#dev-contrib message)
Is https://github.com/python-discord/sir-lancebot/pull/1211 in a state that a revert could be done until the work for a slash command is ready?
It's likely only the vocal few who used the command on a regular; however the lack of a reliable bookmark feature is missed.
I wonder if this needs to actually be a separate option. On the surface we could just replace the behavior of concatenating several blocks into this. Then again not everyone might find ipython intuitive without prior experience. We could make it default to a usual run if there's up to one codeblocks, and an ipython run otherwise. The error coloring is a very nice bonus.
af20178 Bump pre-commit from 3.0.4 to 3.1.0 (#86) - dependabot[bot]
We should set the default permissions here, so that by default this isn't available in-guild
his shouldn't be double-indented (maybe add a trailing comma while you're editing this too)
This is out of date with the new behaviour.
Approved, anyone who wants to pick this up feel free to comment here.
The PR can't be directly reverted as it came with a number of refactor commits too.
[bot] Branch use\-paste\-service\-for\-long\-autoban\-filters was force-pushed to `5caa395`
Done in 6047ad7165a16ae499d95766ad3dfc20a64c5a63
Code looks good to me, will test after a few hours.
There's a typo in the docstring of send_weekly_autoban_report method, btw.
If chanel is not specified, it is sent to #mod-meta.
line 316.
Updated in a6fe30adc6aa611e042006659f4dcc8aa135b7b9
GitHub Actions run 4284002286 succeeded.
The docs say:
Setting an empty permissions field will disallow anyone except server administrators from using the command in a guild.
By default, upon instantiation, it defaults to none since the callback doesn't have the __discord_app_commands_default_permissions__ attribute, so I'm wondering if that counts as the same ?
If not, i'll just add this then
self.delete_book_mark_context_menu.default_permissions = []
GitHub Actions run 4285979073 succeeded.
679cb77 Migrated !tags command to slash command /tag - Ibrahim2750mi
1cff5bf Update tests for /tag as of migration to slas... - Ibrahim2750mi
861f5b2 Merge branch 'main' into migration/tag - Ibrahim2750mi
1bd0310 Merge branch 'main' into migration/tag - Ibrahim2750mi
9b98dfe Implement all reviews - Ibrahim2750mi
[python-discord/bot] Checks Successful on PR: #2403 Migrated `!tags` command to slash command `/tag`
GitHub Actions run 4286084826 succeeded.
Connected!
GitHub Actions run 4286123382 succeeded.
GitHub Actions run 4286502285 succeeded.
GitHub Actions run 4286687774 succeeded.
GitHub Actions run 4286868772 succeeded.
- Added title to all the embeds
- Changed any mentioning of
!tagscommand
If someone reviews please make sure to double-check if there is any mention of !tags and also please ensure there is a new line at the end of the file(my automated script messed up somethings, also I wonder if it would have been done faster manually)
GitHub Actions run 4287265980 succeeded.
[python-discord/bot] New review comment on pull request #2419: Migrating tag embeds to app\_commands
title: "Contribute to Python Discord's open source projects"
These are proper nouns, so should be capitalised.
[python-discord/bot] New review comment on pull request #2419: Migrating tag embeds to app\_commands
Why was this section removed?
[python-discord/bot] New review comment on pull request #2419: Migrating tag embeds to app\_commands
title: "Mutable default arguments"
[python-discord/bot] New review comment on pull request #2419: Migrating tag embeds to app\_commands
title: "Sending images in embeds using discord.py"
[python-discord/bot] New review comment on pull request #2419: Migrating tag embeds to app\_commands
title: "Positional vs. keyword arguments"
I am really sorry it might have been accidentally removed by the script.
GitHub Actions run 4287573821 succeeded.
Only one channel was mentioned in this tag for a reason, could you please change it back.
Did you mean for this to be removed?
GitHub Actions run 4287645927 succeeded.
GitHub Actions run 4287679957 was cancelled.
GitHub Actions run 4287691738 succeeded.
Connected!
GitHub Actions run 4287752654 succeeded.
I can take this.
Just to be clear, we just want the same .bm implementation from before, without any changes?
GitHub Actions run 4287796998 succeeded.
GitHub Actions run 4287802855 succeeded.
GitHub Actions run 4287846329 succeeded.
d091b1d Contributing Page->Sir Lancebot: update descrip... - Ibrahim2750mi
a82c4bf Update description of TRASHCAN_EMOJI accordin... - Ibrahim2750mi
7378c28 remove trashcan emoji from required variables - Ibrahim2750mi
72a070d Merge branch 'main' into contributing/sir-lance... - wookie184
394f5db Merge branch 'main' into contributing/sir-lance... - Xithrius
GitHub Actions run 4287914219 succeeded.
GitHub Actions run 4287996092 succeeded.
GitHub Actions run 4288079780 succeeded.
This is only a code review, will test it later on.
Other than that, this looks beautiful !
Wouldn't it be a better idea to move these to their own section maybe in the config file ?
Wouldn't this fail if the channel is not in cache ?
If that's the case, then we might end up with a null value for that channel .
We could either add our own get_or_fetch to bot-core, or have a null-check here.
Danny said that get_or_fetch is not there on purpose, here's the issue for reference.
Same thing about the get_channel here, it might even start to be redudnant :/
I liked the way we crossed off the name before, it's more catchy that way.
Can't we combine them both ? e.g cross off the name and say that they're not part of our server anymore ?
This change eliminates the information that would answer the question "what was reduced?"
Perhaps something like "Keep in mind this is not an exact replica of the real server; for simplicity, some groups of channels from the real server are represented by only one."
It's not commits that are ignoring the env file--it's git. Perhaps this can be changed to "Git will ignore the .env file", or "Git will ignore the .env file, and you shouldn't try to track changes to it anyway."
I would prefer "The bootstrapping script is a Python program, so you will need a compatible Python version with these packages installed:"
This invalidates all the time I spent two weeks ago doing exactly that, and I refuse to accept that other people might get a QoL improvement when it's too late for me to benefit from it. /s
"If you decide to set the configuration values manually, you will only need to set the values for the channels, roles, categories, etc. that are used by the component you are developing."
Have we considered a URL button for the embed? Or would that be too big?
What do you mean by "the result would be ephemeral"? Anyone can see the output right?
@mbaruh: No, the resultant message would be only visible to the person who ran the command. So it shouldn't add any clutter for anybody else in the channel as well.
As for the viability of the feature itself - I'm not entirely sure it's really an improvement over the existing !eval command. There are limitations and I don't see a context menu fixing a major problem that the !eval command already has. I would not be averse to just closing the issue.
Short, concise, and links to a more detailed article. A perfect combination for tags. LGTM :+1:
GitHub Actions run 4290070581 succeeded.
GitHub Actions run 4290927794 succeeded.
I'm not too sure about that either, because If I understood right, we'll be revamping the test server as well so that it reflects the necessary channels for the bot to work.
AFAIK, we've only condensed the test server channels to avoid the config hell that we used to go through, which will soon change.
What I meant by "this is not an exact mirror" is the fact that not ALL channels from prod are here since they're not needed for the bot to work, but maybe we should work on that rewording, ...
It pains me that we all had to go throught as well, I share your pain :')
Either that or we say that they will be ignored in commits.
But I'd say let's go with what you proposed since it's all done by git
How about this ? bfa955417ae582a797c31dd462bb0279fb67c64e
GitHub Actions run 4291033858 succeeded.
Done here 30033da4c74df1ae47e30f4a63eef7085b06712f
Let me know if you still want to reword that
GitHub Actions run 4291064625 succeeded.
Sweet, i dragged & dropped that here fefe1e7b80ee6d8f162695d47260d818a414e034
GitHub Actions run 4291096295 failed.
I struggled a bit with myself here to whether I should add it or not.
The purpose was to reduce confusion & to explain the different scenarios that can happen when Pydantic is picking up values.
What do you say to having a brief explanation in its own markdown file & page ?
C'est bon ! 1c23a1715496332a25f2548e208e4e09c31d8be9
This needs to change to comply with the news tags slash command
#2419 is your friend
GitHub Actions run 4291454177 succeeded.
Blocked for further discussion, please open an issue in python-discord/meta.
Currently snekbox returns this error message

Which is not descriptive enough to show that we don't explicitly support input() and it can be just replaced by a string.
#2255
I think that's a separate issue that could be opened on this repo though. Even if we did support input users would get an EOFError if they forgot to supply it, so improving that response woul...
8efb3a2 Bump python-dotenv from 0.21.1 to 1.0.0 (#40) - dependabot[bot]
830c628 Bump alembic from 1.9.3 to 1.9.4 (#39) - dependabot[bot]
Hey there,

Here (https://www.pythondiscord.com/pages/guides/pydis-guides/contributing/sir-lancebot/) it says Python 3.9 is needed to run sir-lancebot but when trying to run the bot with poetry it says that you need python 3.10. On the setup page of the other bot it says 3.10 so it's correct there.
Should be a quick fix.
Youโre correct, it needs updating. Would you like to fix it?
I haven't set up the project yet and for now my plan is to contribute on the bots only since i don't have any experience with django. So feel free to fix it.
3047532 Bump aiohttp from 3.8.3 to 3.8.4 (#38) - dependabot[bot]
GitHub Actions run 4293792689 failed.
GitHub Actions run 4293827906 succeeded.
GitHub Actions run 4294333740 failed.
Hello,
not sure if should ask in this issue or in #2420.
I'd like to work on improving the error message. If I understood things right the plan is to just improve the error message and not integrate the possibilty of using input().
GitHub Actions run 4294493691 succeeded.
I'd like to work on improving the error message. If I understood things right the plan is to just improve the error message and not integrate the possibilty of using input().
Well I thought to implement the issue myself after it got approved but now will try to find something else.
Oh, sure sorry. I didn't want to take it away from you.
GitHub Actions run 4294748603 succeeded.
Connected!
GitHub Actions run 4294945587 succeeded.
GitHub Actions run 4294964451 succeeded.
GitHub Actions run 4295102428 succeeded.
Not sure if this issue is still active since it has already been a year :D
What do you think about creating a "/remind" command for reminder? It could have day, month, hour etc. as optional parameters that you can enter. That would make it easier to not get confused with the proper format.
However, I am not sure if that makes things actually easier and nicer to use.
It's been a while since this discussion was active but i really like the idea.
I just tested everything but for me there seems to be a problem when snoozing a timer for the second time. I get the option to snooze again and when i click it I can also select for how long i want to snooze but then it says "This interaction failed". Did this happen to any of you as well?
Yeah, i'm not sure what our general policy on this should be now. I know we wanted to try and keep the config file fairly concise and remove unnecessary things, although making durations easily configurable for development would probably be helpful.
Normal text channels (i.e. not threads) should always be cached, it's something we assume quite a lot throughout the bot.
I do agree that this isn't ideal, although i'm not sure what the nicest approach is. At the very least it's annoying to have my editor complain that it could be None.
Since it's something that shouldn't be None, I don't think we should just ignore if it is (e.g. early return), as this could hide some bugs.
One solution is something i'd thought of when thinki...
The check just aims to remove people who have e.g. forgotten about the server or don't use it any more, rather than being a specific "activity quota". That's the reasoning for counting any messages as some activity.
We could have it as some sort of very low activity quota, although it would require some discussion for what value to choose, and the value picked would be somewhat arbitrary.
I generally prefer actual text since it's explicit and doesn't require any knowledge of the actual meaning. Since users without activity in the past 30 days will be removed anyway, there should be fewer users not on the server on the list.
GitHub Actions run 4296105153 succeeded.
Connected!
GitHub Actions run 4296102840 succeeded.
Closing this as I don't think there's anything we can do and it doesn't seem to have appeared since.
Ah I didn't realise our get_or_fetch channel already never returned None, i'll use that https://bot-core.pythondiscord.com/main/output/pydis_core.utils.channel.html#pydis_core.utils.channel.get_or_fetch_channel
GitHub Actions run 4296752427 failed.
The issue was actually in a different file, the comment here was just a copy paste. b67e849
I always mix them up 4d51cad
I knew there were usages I forgot to bring back ๐ bd5c0f8
What about these
content: str | Iterable # What actually needs filtering
action_descriptions: list = field(default_factory=list) # What actions were taken
These are out of date, new values are:
snekbox_eval_api: http://snekbox-310.default.svc.cluster.local/eval
snekbox_311_eval_api: http://snekbox.default.svc.cluster.local/eval
New environment variables deployed under new-bot-env, ready to be migrated when we merge this PR.
GitHub Actions run 4297226955 succeeded.
Tadaa a839fa59d9fae8151401e309eda29dc680503bed
GitHub Actions run 4297241987 succeeded.
Relevant Issues
Closes #1219
Description
Undeprecated the .bookmark command, for reasons outlined in #1219. A majority of the code and logic was a straight copy paste from an older version of this repository, however some changes have had to be made to be compatible with the new version (as the rewrite to a context menu command had come with other code changes as well)
Did you:
- [x] Join the Python Discord Community?
- [x] Read all the...
GitHub Actions run 4297504895 succeeded.
@MrHemlock Do you still remember those couple ideas?
I had a chat with him, he said he doesn't remembers the ideas. However I think we can implement this like how we have implemented the codeblock one.
Seems fine in testing - is there anything I should be looking out for due to the changes made that weren't an exact copy?
I think the nicest way would probably be to leave the error message as is and insert a message above/below it with information, something along the lines of:

Sure, I also think the same. Assign the issue to me and I will make a quick pr.
I somehow missed action_descriptions, but for content the type of Iterable depends on the filter list. It might be more useful here to expand the comment.
Proposals for similar ideas have been rejected, the worry being that deleting user messages is quite a confusion user experience and it's annoying to lose your message, so I'm not sure this is something we would want.
Some of the previous discussion is here:
https://github.com/python-discord/meta/issues/78
https://github.com/python-discord/bot/issues/2116
[python-discord/sir-lancebot] Pull request review submitted: #1223 Undeprecate bookmark text command
Looks great, just a few small nitpicks
target_user: discord.Member | discord.User,
f"Click the button to be sent your very own bookmark to "
I'm just putting this so that future reviewers are aware, but also so that you don't end up doing something that belongs to a separate issue in case you get comments about this. But currently, if DMs are closed, and you try to bookmark a message, you'll get the view that says "Receive bookmark", and if you click on it it'll tell you that you've already received it, when in fact you haven't.
Relevent issue is #1179, and should be implemented & fixed there
Too bad we can't make this ephemeral :/ I don't like showing that someone has their DMs disabled much
Here's how it currently displays

GitHub Actions run 4300613689 succeeded.
Proposals for similar ideas have been rejected, the worry being that deleting user messages is quite a confusion user experience and it's annoying to lose your message, so I'm not sure this is something we would want.
Why don't we implement it like the codeblock thingy? We wouldn't delete the messages, we would just tell them to use pastebin for further use?
Closes #2420
Closes (MAYBE) #2255
We could check if EOFError is in the result (as well as maybe checking that "input" is on their code and the status code indicated an error), and if so add a message after the codeblock saying that input doesn't work with the bot.
No need to check if input is in their as the docs say EOFError is only raised when
the input() fun...
GitHub Actions run 4303002057 succeeded.
This looks superb !
Just a couple of questions & nitpicks here & there.
I have done some basic api testing and I haven't really noticed anything just yet.
I'll come back to approve this once I'm done with the bot testing part :D
Shouldn't we make this a reversible operation ?
I say that because all the default migrations are mostly reversible, and for this case, we'd need to provde a an sql scrupt to the reverse_sql kwarg
"""Create the 'antispam' FilterList and its related Filters."""
help_text="Channels in which to not run the filter even if it's enabled in the category"
I suppose ?
Just curious, are you passing False to the null kwarg for explicitness ? because they default to False IIRC
We can probably condense this one & _create_filter_list_meta_extra_kwargs like this
def _create_meta_extra_kwargs(for_filter_list: bool) -> dict[str, dict[str, bool]]:
"""Create the extra kwargs of the for either FilterList serializer's Meta class."""
extra_kwargs = {}
for field in SETTINGS_FIELDS:
field_args = {} if for_filter_list else field_args = {'required': False, 'allow_null': True}
if field in ALLOW_BLANK_SETTINGS:
field_args['al...
should also sanity check the user had "input" in their code, IMO.
Or the message should be altered to include stdin.
As mentioned in the PR description, the docs say EOFError is specific to input, so i'm not sure what use case this would catch.
This thought didn't cross my mind earlier what if someone raises the EOFError
This thought didn't cross my mind earlier what if someone raises the EOFError, we should probably add a check for this.
I don't think we need to add a check, I don't know why someone would raise the error manually, and even if they do the warning isn't incorrect, just unnecessary.
This can be closed now as the source commands works for tags.

According to these lines
# Files directly under `base_path` have an empty string as the parent directory name
tag_group = parent_dir.name or None
tag_group will be None until the tag is in a sub-directory inside bot/resources/tags/ eg: bot/resources/tags/fstring/fstring.md and currently we don't have sub-directories in the folder.
Moving them to sub-directories might also solve #2...
I think the !source command should be made a slash command because, similarly to the reason why we made !tags a slash command, it would make it easier to look up the name of a cog without having to leave the Discord channel if you don't exactly remember the name offhand.
The intent was to sort tags into groups and sub-directories but no one has taken it up yet. I'm firmly against removing this feature just because we haven't used it yet.
For instance, all the d.py related tags can go into a subdirectory, it just requires someone making that PR
This is the reason I made the issue(if there already an issue for this, then I am sorry), I could sort them up in the sub-directories.
But first I think we need to finalise the groups we are going to have. I am thinking something along these lines.
- python-strings
Tags related to stringsfstring,str-joinetc. - python-discord
Tags related to us likecodeblock,ytdl,xyproblemetc. - discord.py
Tags related to d.py - A-vs-B (can't seem to figure out a better name for t...
I don't think we need to create groups for every single tag or for most tags. Any additional grouping we add means you need an additional term to invoke it. With your proposal, calling the pep8 tag would be !python-environment pep-8. So I want to really avoid grouping things just to group them, there should be a natural purpose to it besides "we're not using this code feature yet." The purpose behind groups was to avoid cluttering the namespace and avoid conflicts around calling tags, so th...
Can't we do something like we only require the group name for triggering some specific group tags, an example would be dpy and use the other groups to list the tags in the embed more cleanly? We can check if the tag.group is an enforced(enforced meaning it would require the user to add the group name before the tag to invoke it) group if not then it can be triggered by both !group tag and !tag? For dpy we can make it an enforced group.
I assume we'd also implement autocomplete here?
Yes, that's what I was referring to when I said "it would make it easier to look up the name of a cog"
Hey there's one thing I forgot, the current bootstrap doesn't handle off-topic channels which automatically change names every 24 hours. Can we special case OT channels during bootsrap? Generally, the names will always take the form of ot<int>-name..., and be in the Off-Topic category. If you have a preferred implementation, please proceed with it, otherwise let me know.
Let's drop this. it's only used for a (now unused) whitelist. If you stumble upon any unused constants like this, feel free to drop as well.
GitHub Actions run 4312562275 succeeded.
GitHub Actions run 4313186106 succeeded.
Hey there's one thing I forgot, the current bootstrap doesn't handle off-topic channels which automatically change names every 24 hours. Can we special case OT channels during bootsrap? Generally, the names will always take the form of
ot<int>-name..., and be in the Off-Topic category. If you have a preferred implementation, please proceed with it, otherwise let me know.
It's been handled in 4b4b65bfe5b923e9c2ac6f6cc137210fa936ccdf
GitHub Actions run 4314615115 succeeded.
GitHub Actions run 4314636549 succeeded.
GitHub Actions run 4314647489 succeeded.
GitHub Actions run 4314760485 failed.
GitHub Actions run 4314956919 succeeded.
GitHub Actions run 4316318190 succeeded.
# the error and the error is not manually printed by the author with a syntax error.
if results["stdout"].rstrip().endswith("EOFError: EOF when reading a line") and results["returncode"] == 1:
warning_message += ":warning: Note: `input` is not supported by the bot :warning:\n\n"
I'd suggest:
- Double quotes for consistency
- Using
results["stdout"]instead ofoutputso the warning is still displayed if the error doesn't fit ...
The issue is still there, although only if the cogs are loaded in a certain order. Running !ext reload tags should allow you to reproduce the issue.
@shtlrs do you think it would be easier to do this now, or in a new PR once #2408 is merged to avoid conflicts? I'm happy to do either.
076f071 Use get_or_fetch_channel instead of get_channel - wookie184
GitHub Actions run 4316922825 succeeded.
Also wookie thanks for reviewing
GitHub Actions run 4318621138 succeeded.
GitHub Actions run 4318634893 succeeded.
GitHub Actions run 4318634883 succeeded.
GitHub Actions run 4318637249 succeeded.
GitHub Actions run 4318639103 succeeded.
GitHub Actions run 4318660094 succeeded.
[python-discord/king-arthur] New branch created: Fix\-cronjob\-integrations
[king-arthur] Branch Fix\-cronjob\-integrations was force-pushed to `3b70a2a`
GitHub Actions run 4318741568 was cancelled.
GitHub Actions run 4318743616 succeeded.
I'm changing rule 4 to always blame Chris ! :BB
e87a1fa Bump Discord.py to 2.2.2 - ChrisLovering
094a47c Don't override the default list of ignored flak... - ChrisLovering
85a1b41 Explicitly set the stack level of the warnings.... - ChrisLovering
a6e3547 Bump dependencies to latest - ChrisLovering
[python-discord/bot-core] New branch created: Bump\-dependancies
[python-discord/king-arthur] branch deleted: Fix\-cronjob\-integrations
GitHub Actions run 4318855028 succeeded.
Yea. Also, since it was marked as a feature it was getting rolled into 9.5.0, since releases doesn't see a feature as a valid patch release. See https://bot-core.pythondiscord.com/main/changelog.html
should this not be a part of get_results_message?
05fe91a Update readme regarding default output path and... - ionite34
[python-discord/bot-core] branch deleted: Bump\-dependancies
fff9d1a Bump Discord.py to 2.2.2 - ChrisLovering
4aebfae Don't override the default list of ignored flak... - ChrisLovering
247e6a3 Explicitly set the stack level of the warnings.... - ChrisLovering
79b8734 Bump dependencies to latest - ChrisLovering
[python-discord/bot-core] New tag created: v9\.5\.1
Then we would aslo need to probably return the warning_message as well, which doesn't suits the function to return a string specifically for one outcome when it can be better sorted elsewhere.
I don't think it's really needed here since the only usage of this is 1 line at
return EvalResult.from_dict(await resp.json())
where resp.json() wouldn't be typed anyways. If we weren't using the dataclass in internal API and passing the dict around instead then it might be more useful to have a TypedDict.
This adds a "main" workflow that'll be triggered upon pull_request or push to our repo's main branch, which would then "orchestrate" the other workflow that needs to be ran
Build & deploy have been fused together since they basically need each other to run.
main.yml will always lint & test, then:
- If it's a pull request event, it'll just trigger the status embed
- If it's a push due to a merge of a pull request, it'll lint & test, build & deploy, then creates a sentry release
GitHub Actions run 4319055079 succeeded.
d3f906f Allow uploaded files to be writeable in nsjail - ionite34
Adding a dependabot config is likely a good idea too
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "daily"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "daily"
reviewers:
- "python-discord/devops"
- uses: azure/setup-kubectl@v3
- name: Authenticate with Kubernetes
uses: azure/k8s-set-context@v3
with:
method: kubeconfig
kubeconfig: ${{ secrets.KUBECONFIG }}
e95f4cc251218383e7a4d6c4bcd225404d6f4a0a
e733a18242d4fdb9d23d494aa66e0576916fade0 & c9d258652a84a5388d2ddf4b856916e4c0441166
1dd4585370a95cf6b2cb2135da23a9530e06d82e
e733a18242d4fdb9d23d494aa66e0576916fade0
uses: ./.github/workflows/lint-test.yml
uses: ./.github.workflows/sentry_release.yml
Gonna need a new line here
nit
- "python-discord/devops"
Covered in my comment above
04ed41798f0b135adeeb6b55d9b5749309d7f419
sdljksdkljhsdlkjskdhsdlkjhsd ...
c9fc557bb1266c8b847fe8e14e5c91b4cd434d66
8cc0b6b2eadf33c3f6c5808c65743c6983eca822
8cc0b6b2eadf33c3f6c5808c65743c6983eca822
04ed41798f0b135adeeb6b55d9b5749309d7f419
63cff79dacae5d8dd149bb1618018c1c9e4d8d77
GitHub Actions run 4320698762 succeeded.
GitHub Actions run 4321227688 succeeded.
Connected!
GitHub Actions run 4321237919 succeeded.
GitHub Actions run 4321243045 succeeded.
GitHub Actions run 4321252859 succeeded.
GitHub Actions run 4321250980 succeeded.
Connected!
Is there a reason we would rather implement a file ignore system than disable Python bytecode generation? Are there eval use cases that would rely on it being generated?
Does the current ignore system support ignoring directories? The fnmatch docs state that a forward slash is not treated specially, but I'm unsure of what that means in practice. In any case, it looks more limited than gitignore so documentation is better off avoiding making such comparison.
02c6957 Bump pre-commit from 3.1.0 to 3.1.1 (#1221) - dependabot[bot]
Connected!
Very good, you have done well.
Thanks for the contribution!
GitHub Actions run 4321292658 succeeded.
