Open Bluenix2 opened 2 years ago
I don't have much to contribute to the discussion since I'm still relatively new to programming. I'd rather use this opportunity to absorb what I can from those with more experience. Still, I find the API
interaction with bot
and vice-versa fascinating and am excited to take on this issue if approved!
Since I am new to open source and am looking for my first contrib. I would like to try to tackle this issue with another willing person.
Is the issue still open?
I don't know to be honest, I only see that its still open here.
@Bluenix2 just so I understand it correctly: is this about having an endpoint that exposes the query parameter filtering support of site endpoints?
Ok, it seems I missed the mark. Is this about exposing the filters in this dictionary? https://github.com/python-discord/site/blob/main/pydis_site/apps/resources/views/resources.py#L68
Ok, it seems I missed the mark. Is this about exposing the filters in this dictionary? https://github.com/python-discord/site/blob/main/pydis_site/apps/resources/views/resources.py#L68
Yeah I think that's the idea.
Currently if the !resources
command is given an argument e.g. !resources web development
, the link will filter the topic by web development (links to https://www.pythondiscord.com/resources/?topics=web-development). This would potentially allow fuzzy matching for topics, or extending it to match on things other than topics (e.g. it could tell that !resources free
wanted https://www.pythondiscord.com/resources/?payment-tiers=free).
If we want to do this it would probably be worth having a bot issue with a concrete use case for the endpoint first, so we don't add something we wont use, and we can ensure the endpoint includes what is needed. I somewhat question whether it's necessary, given the person can just filter what they once when they're on the page.
The resources command currently does no validation for the given argument. There is this new issue https://github.com/python-discord/bot/issues/2510, which I think is very reasonable, but I would rather the bot didn't spit back arbitrary strings given by the user (both for the correctness of the provided URL and from a moderation perspective). I think that's already a solid use case for this feature.
Summary
Following python-discord/bot#2079 it was discussed having an API allowing the bot to fetch possible filters so that implementations don't need to scrape it.
This new API could power different future bot features like having interaction-based URL builder.
Description
Currently resources are loaded from a folder of yml, then a number of different steps in processing are applied to sort out all filters and its topics. This is a highly dynamic system which will complicate this PR.
The API resides in
pydis_site/apps/api
whilst the resources is in its own app atpydis_site/apps/resources
(the actual view is inpydis_site/apps/resources/views/resources.py
) which complicates things. See, for the API backend to get access to that information there needs to be an import there or loading - which might be unwanted.This means that the implementation might be a bit more complicated than one might first think. The easiest way to go about this would be placing the route under
resources
but it is still, technically, part of the API. Another option would be duplicating the processing, inside of API, but that still requires access to the folder of resources meaning that we are back at square one of having unwanted coupling.Assignee
@iamericfletcher has asked to implement this (I couldn't assign them directly). Please note that this is still in planning.