examples/README.ytfeed: finish ytfeed README for now
This commit is contained in:
		
							parent
							
								
									1da34ef6ab
								
							
						
					
					
						commit
						3d68a0da43
					
				@ -4,6 +4,38 @@
 | 
			
		||||
__/  /  /   /_  /_  /_/  /__\  public domain 2020-2025
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
I wrote ytfeed's 1.0 as ytfeed.py (an all-Python project) in 2020-2021 as I
 | 
			
		||||
finished high school, partly as a tool I wanted and partly as a learning
 | 
			
		||||
opportunity. My use of ytfeed.py as a learning project ended up undoing its
 | 
			
		||||
usefulness and turning it into a >1KLoC monster that could rewrite itself
 | 
			
		||||
(really) and had helper functions for every trick in the book. The menu system
 | 
			
		||||
in particular was the hardest part to make feel /good/ (or at least decent,
 | 
			
		||||
compared to a TUI) and spanned half the size of the project. I gave up on it
 | 
			
		||||
after failing to beat it into some shape (I thought I could rewrite ytfeed.py
 | 
			
		||||
in POSIX shell, which is definitely possible but definitely impractical) and
 | 
			
		||||
put the code tarballs on the Internet Archive, hoping someday I could revisit
 | 
			
		||||
it.
 | 
			
		||||
 | 
			
		||||
Now, thoroughly an adult, I present the product of a number of years'
 | 
			
		||||
reflection on what I could have done better. I started using this program as
 | 
			
		||||
soon as it was workable and it remains my favorite design for a YouTube client.
 | 
			
		||||
There are plenty of little hiccups and inconveniences that make it difficult to
 | 
			
		||||
recommend to others, but I use this client daily (or so) and I hope others find
 | 
			
		||||
it to be useful for themselves.
 | 
			
		||||
 | 
			
		||||
Originally it was pronounced "youtubefeed" really fast, so that I could gloss
 | 
			
		||||
over the fact that it is a program that only exists because YouTube does. Then,
 | 
			
		||||
"whitefeed", as a nice pun and to reflect that I would be adding general RSS
 | 
			
		||||
support. Then I stopped caring about RSS and never added the support, so I call
 | 
			
		||||
it "whitefeed" in my head and "my little YouTube client" out loud. You may call
 | 
			
		||||
ytfeed whatever suits you and your form of communication, and also you may do
 | 
			
		||||
so for literally every formation of characters; it's your life, dude.
 | 
			
		||||
 | 
			
		||||
ytfeed relies upon YouTube's RSS feed support which somehow has not yet been
 | 
			
		||||
killed by Google. For good luck, don't breathe a word of it to any Alphabet
 | 
			
		||||
employees. It is clunky - requiring a UCxxxx channel ID is weird - and it is
 | 
			
		||||
reliable - it uses the network sparingly by design.
 | 
			
		||||
 | 
			
		||||
ytfeed(6) is a small and simple YouTube client made using menu(1). ytfeed(6)
 | 
			
		||||
exists as a demonstration of menu(1), menu(1) was written as a component of
 | 
			
		||||
ytfeed(6), and they were both written for my own personal use.
 | 
			
		||||
@ -19,6 +51,9 @@ the entries from both feeds.
 | 
			
		||||
ytfeed.dl(1) is a tool to download a YouTube RSS feed using curl(1) or wget(1)
 | 
			
		||||
and store it in the location used by ytfeed(6).
 | 
			
		||||
 | 
			
		||||
I don't care to document the others because they will change. Also, ytfeed's
 | 
			
		||||
API in general (use of stdin and argv) is not finalized and will likely change.
 | 
			
		||||
 | 
			
		||||
The Python programs are especially short, exclusively use Python's standard
 | 
			
		||||
library, and are written to (hopefully) work on a reasonably recent Python 3
 | 
			
		||||
interpreter. Unfortunately Python will probably shit itself anyway when you try
 | 
			
		||||
@ -28,11 +63,9 @@ as part of the standard library - I figured it'd be less hassle than vendoring
 | 
			
		||||
a dependency or (woe be unto those who think it) relying on whatever awful
 | 
			
		||||
package managers the user has installed.
 | 
			
		||||
 | 
			
		||||
ytfeed's API (use of stdin and argv) is not finalized and will likely change.
 | 
			
		||||
 | 
			
		||||
At some point I'd like to refactor the project to be able to do something like
 | 
			
		||||
```
 | 
			
		||||
$ ytfeed.browse-feeds \
 | 
			
		||||
``` sh
 | 
			
		||||
ytfeed.browse-feeds \
 | 
			
		||||
	| menu \
 | 
			
		||||
	| ytfeed.browse-feed \
 | 
			
		||||
	| menu \
 | 
			
		||||
@ -40,5 +73,13 @@ $ ytfeed.browse-feeds \
 | 
			
		||||
	| menu
 | 
			
		||||
```
 | 
			
		||||
because I find long pipelines to be satisfying. Also, the Python programs would
 | 
			
		||||
benefit from sharing code rather than duplicating it (just a few functions - I
 | 
			
		||||
promise!).
 | 
			
		||||
benefit from sharing code rather than duplicating it (it's just a few functions
 | 
			
		||||
- I promise!).
 | 
			
		||||
 | 
			
		||||
Features from ytfeed.py I will not be including:
 | 
			
		||||
	- a custom configuration file format
 | 
			
		||||
	- a better custom configuration file format (with flow control)
 | 
			
		||||
	- a migration tool from the older to the newer config format
 | 
			
		||||
	- ability to modify the program live from within the program
 | 
			
		||||
		(technically this is now easier but I don't want to)
 | 
			
		||||
	- self reproduction
 | 
			
		||||
 | 
			
		||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user