api VS tube-cast

Thank you for the response!

> support splitting ingredients by typing a comma

That sounds sensible, yep; filed as https://github.com/openculinary/frontend/issues/210

> "Are there any ingredients that are not available?" ... I knew what you meant, the search will exclude recipes with those items, but it felt weird to read

That makes sense too. If I remember correctly, that prompt was most-recently rephrased during a pandemic-related lockdown (with subsequent unpredictable ingredient shortages), and so that context may have affected the choice of language; but I agree that it's odd phrasing and should be updated.

Hopefully that'll be a relatively quick correction, although it will require internationalization (currently machine-translated without review by native language speakers, not ideal); it's filed as https://github.com/openculinary/internationalization/issues/...

> box around the search form has a huge gap to the right of the form inputs

> I'd probably expect to see filters for vegan/veggie/pescatarian / low gi etc but then maybe not

Two good points here, and possibly combinable. Perhaps those dietary recipe filters could be placed in the excess space available next to the search controls.

Today the search API does theoretically support filtering[2] on a few dietary properties -- but that functionality isn't yet visible and available to the user.

Feature request filed as https://github.com/openculinary/frontend/issues/211

- Shopping list feature ... your icons seem too small and fiddly, and I'd want a few buttons on screen of common things - so I can tap those instead of typing

That sounds smart. This feature (and the meal planner) are under-attended relative to the recipe search/explore components, in my opinion. Let me think about this for a while, there are a few considerations and I'd like to be concise.

[2] - https://github.com/openculinary/api/blob/72075f66cd6fda5b809...

Thanks for sharing this!

https://www.reciperadar.com/ does (potentially, as per the notes on the page) pass.

To provide further assurances to users, all of the code[1] to run the service is made available to the public, including logging/analytics functionality[2].

It's (currently?) hard to guarantee to end users that there aren't any other tricks going on, and to match the version running in production (on a single computer in my office room) to the relevant git commit, but the goal is to incrementally move in the direction of additional (verifiable) transparency for the service.

[1] - https://github.com/openculinary/

[2] - https://github.com/openculinary/api/blob/24ac611b1c14b754f23...

https://pypi.org/project/tube-cast/

I realized now that I did not include any links to the project

I just published my first Python PyPi package It's a command-line tool that converts YouTube videos into Anchor FM podcasts. If you you like it please star it on GitHub abe-101/tube-cast

I recently published a command-line tool written in python that'll convert a YouTube video into a Podcast (anchor.fm)

https://pypi.org/project/tube-cast

Under the hood the tool uses yd-dlp to download the video and pyppeteer to publish it on the site anchor.fm as a podcast.

I could use help with documentation and testing

https://github.com/abe-101/tube-cast