Simplify subscriptions.yaml

[jmbannon]

An extension of https://ytdl-sub.readthedocs.io/en/latest/config.html#file-preset

Have the ability to do something like:

# applies to entire file
 __preset__:
   preset: "playlist_preset_ex"
__value__: "url"

# applies for subsequent URLs
__jazz__:
  overrides:
    genre: "Jazz"

jazz_artist1: "url"
jazz_artist2: "url"

# NEW sub-preset, discard __jazz__ and apply __rock__
__rock__:
  overrides:
    genre: "Rock"

rock_artist1: "url"
rock_artist2: "url"

[jmbannon]

Alternative idea: have the presets reside in the config.yaml, then do:

jazz:  # applies jazz preset
  jazz_artist1: "url"
  jazz_artist2: "url"

rock:
  rock_artist1: "url"
  rock_artist2: "url"

Also could add support for nested presets:

tv_shows:
  recent_vids_only:
    author: "url"  # applies tv_shows + recent_vids_only preset

  cooking:
    author2: "url"  # applies tv_shows + cooking preset

youtube_discography:
  jazz:
    recent_vids_only:
      jazz_artist1: "url"
    jazz_artist2: "url"

  rock:
    rock_artist1: "url"
    rock_artist2: "url"

[Behem07h]

The text editor I use (notepad++) has collapsible indents, which helps make my subscriptions.yaml much more readable when i'm trying to edit it. Because of this I personally would much prefer

__preset__:
    preset: "multiurl_music_preset"

jazz:
    jazz_artist_1: 
        download:
            - "url 1"
            -  "url 2"
            
rock:
    rock_artist_1: 
        download:
            - "url 1"
            -  "url 2"

where "jazz" and "rock" are variables we can reference, just like {subscription_name} is. This is quite similar to your second proposed format, but it avoids the potential "preset bloat" of needing to have a ton of presets that only really change one or two variables.

I do like your 1st proposed format, but I think it would be better used for the purpose of combining multiple subscription files into 1 file, by changing the "global" preset half way. If used solely for the purpose of defining a genre override variable i think #.1 is too clunky

[psyciknz]

I kind like this one for it's simplicity:

jazz:  # applies jazz preset
  jazz_artist1: "url"
  jazz_artist2: "url"

rock:
  rock_artist1: "url"
  rock_artist2: "url"

Only because it gets a subscription to a single line.....which I guess is all a simpleton like me wants. Even if the overally structure is complicated, then reducing a single subscription to a line that is easily construction while model (either in a terminal app on IOS or some really simple text editor - imo should be the goal.

[jmbannon]

I think I'm definitely set on being able to nest presets, then have the last key/value be the subscription name + subscription value (which maps to an override variable) or an old fashion preset.

re @Behem07h 's idea of being able to set override variables without the need for a preset. I do like that and it would especially be useful for genres. What about this

youtube_discography:  # applies youtube_discography preset
  genre@Jazz:  # the @ signifies to set everything to the right of it into the `genre` override
    jazz_artist1: "url"
  "genre@Japanese Jazz": 
    japanese_jazz_artist: "url"

[jmbannon]

Alternative syntax for the above - not really liking the @

youtube_discography: 
  genre = Jazz:
    jazz_artist1: "url"
  genre = Japanese Jazz:
    japanese_jazz_artist: "url"

[Behem07h]

Another option I just came up with. personally i think this is the cleanest.

__preset__:
    preset: "music_preset"
    overrides:
        genre: "{indent1}"

Jazz:
    jazz_artist_1: "url"
    jazz_artist_2:
        - "url1"
        - "url2"
Rock:
    rock_artist_1: "url"

[jmbannon]

@Behem07h you need a way to tell which list items map to which override variables. The backend would have to assume a list means you want it underneath download, which is too specific

[jmbannon]

I'm hoping to add list support for overrides at some point, perhaps that's can be how it's done in the future

[jmbannon]

Regarding indent1, I like the idea, but would also like to have the ability to 'hide' the config layer when writing subscriptions. The idea being that 'prebuilt configs' could be distributed and users require zero knowledge of ytdl-sub aside from "put your values in this subscriptions file like this".

[Behem07h]

Regarding indent1, I like the idea, but would also like to have the ability to 'hide' the config layer when writing subscriptions. The idea being that 'prebuilt configs' could be distributed and users require zero knowledge of ytdl-sub aside from "put your values in this subscriptions file like this".

In essence my idea was that just like {subscription_name}, we give every indentation its own variable name. for example

{indent_1}:
    {indent_2}:
        {indent_3}:
        etc...
            {subscription_name}:
                - "url"

This way people can use as many indents as they want, and use the variables in their config just like any variable. If the indent didnt exist in the subscription entry it could just return blank.

I showed {indent_1} being assigned to an override variable simply for illustration purposes to show how it all would work

[jmbannon]

Right, I get that. I guess my concern is it sort-of 'locks you in' to a very specific format. That, and it'd be hard in the backend to decide wether it's a variable indent or a preset, i.e.

Jazz:
  "Jazz Artist":
    download: "url"

do you treat indent2 as a subscription name or indent variable? download: "url" could be a valid subscription name + value. The current backend logic is "if the indent is not a preset, it must be a subscription name"