Skip to content

Miscellaneous Subliminal plugin improvements#1304

Merged
cvium merged 6 commits intoFlexget:developfrom
danielkza:subliminal-improvements
Aug 15, 2016
Merged

Miscellaneous Subliminal plugin improvements#1304
cvium merged 6 commits intoFlexget:developfrom
danielkza:subliminal-improvements

Conversation

@danielkza
Copy link
Copy Markdown
Contributor

@danielkza danielkza commented Jul 31, 2016

Motivation/Detailed changes:

  • Use the effective list of providers to validate configuration when possible. Avoids needing to manually update the list to follow upstream.
  • Make it possible to use providers that require login by adding the provider_configs option.
  • Add hearing_impaired option.
  • Make debugging easier by silencing useless spam, and un-silencing subliminal itself.

Config usage if relevant (new plugin or updated schema):

Add provider_configs option

subliminal:
  provider_configs:
    legendastv:
      username: myuser
      password: mypassword

Add hearing_impaired option

subliminal:
  hearing_impaired: yes

@danielkza danielkza force-pushed the subliminal-improvements branch 2 times, most recently from ee280fa to 7bb65b6 Compare July 31, 2016 05:29
@danielkza
Copy link
Copy Markdown
Contributor Author

Fixed Codacy issue.

@danielkza danielkza changed the title Miscellaneous Subliminal plugging improvements Miscellaneous Subliminal plugin improvements Jul 31, 2016
@liiight
Copy link
Copy Markdown
Member

liiight commented Jul 31, 2016

Do all providers need/have relevant config options?
Also, do you think it'll be possible to define a provider directly under root level without needing the providers_config property?

@danielkza
Copy link
Copy Markdown
Contributor Author

danielkza commented Jul 31, 2016

Do all providers need/have relevant config options?

Currently only those that need authentication.

Also, do you think it'll be possible to define a provider directly under root level without needing the providers_config property?

I commented about that in the commit: using only the providers key would make it impossible to set options for some plugins without disabling all the others. An alternative would be to allow a boolean instead of a dictionary for plugins that don't need configuration.

subliminal:
  providers:
    legendastv:
      username: myuser
      password: mypassword
    opensubtitles: yes

It would still not cover the case of omitting providers altogether and fetching from all the providers available. Would having an all key be better?

subliminal:
  providers:
    all: yes
    legendastv:
      username: myuser
      password: mypassword

Which would pass a providers_list of None but have the legendastv key in provider_configs.

@cvium
Copy link
Copy Markdown
Contributor

cvium commented Jul 31, 2016

Couldn't you just do this:

subliminal:
  providers:
    legendastv:
      username: myuser
      password: mypassword

@danielkza
Copy link
Copy Markdown
Contributor Author

danielkza commented Jul 31, 2016

@cvium I just edited my comment above to explain why not.

@liiight
Copy link
Copy Markdown
Member

liiight commented Jul 31, 2016

You could set type to be object or string, then check in code :
'type':['object', 'string'].
If that's not possible I guess leaving it as is is ok.
I think naming the option something like authentication would be better but that's just a suggestion.

@danielkza
Copy link
Copy Markdown
Contributor Author

@liiight I don't think there is any specification that the configs will always be for authentication - it just happens to be the current situation. Using only the providers key does seem cleaner, but the all workaround is quite ugly. Is there any other plugin with a similar situation that we can use as a model?

@cvium
Copy link
Copy Markdown
Contributor

cvium commented Jul 31, 2016

'providers': {'type': 'array', 'items': {
    'oneOf': [
        {'type': 'object',
        'additionalProperties': {
            'type': 'object',
            'properties': {
                'username': {'type': 'string'},
                'password': {'type': 'string'},
            }
        }},
        {'type': 'string'}
    ]
}},

The above will let you do this:

    subliminal:
      providers:
        - legendastv:
            username: myuser
            password: mypassword
        - opensubtitles

@danielkza
Copy link
Copy Markdown
Contributor Author

danielkza commented Jul 31, 2016

@cvium That looks really nice. But what about the option of enabling all available providers? edit: Would an all_providers: yes option be good?

@cvium
Copy link
Copy Markdown
Contributor

cvium commented Jul 31, 2016

I think I prefer having provider_configs

@danielkza
Copy link
Copy Markdown
Contributor Author

What about this:

providers:
  all: yes
  configs: 
    legendastv:
      username: myuser
      password: mypassword

For the case of keeping all providers and configuring some. @cvium's last suggestion would also work.

@paranoidi
Copy link
Copy Markdown
Member

Nay for provider_configs from me, looks like nothing we have currently.

@paranoidi
Copy link
Copy Markdown
Member

Perhaps call the key authentication or login and it makes a lot more sense. I don't think there will be anything else in there?

@cvium
Copy link
Copy Markdown
Contributor

cvium commented Aug 8, 2016

Any progress on this?

@danielkza danielkza force-pushed the subliminal-improvements branch from 7bb65b6 to e57beea Compare August 13, 2016 20:41
Some subtitle providers require authentication. To configure them,
subliminal accepts the `provider_configs` option to the ProviderPool
class. Add support for it through an `authentication` configuration key.

Having the provider configurations be specified in the `providers` key
would look nicer, but break the case where one wants to authenticate to
specific providers, but still use all the available ones (by leaving out
the `providers` option completely).
Dogpile can spam log messages such as the following at the debug level. Silence it.

2016-07-31 00:44 DEBUG    dogpile.util.readwrite_lock subs            <dogpile.util.readwrite_lock.ReadWriteMutex object at 0x7f693c4c08d0> acquired read lock
@danielkza danielkza force-pushed the subliminal-improvements branch from e57beea to 6104823 Compare August 13, 2016 20:42
@danielkza
Copy link
Copy Markdown
Contributor Author

I've renamed the configuration key from provider_configs to authentication and rebased to the latest of the develop branch.

try:
from subliminal.extensions import provider_manager
PROVIDERS = provider_manager.names()
except ImportError as e:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you don't use the exception it's better not to include as e.

Copy link
Copy Markdown
Contributor Author

@danielkza danielkza Aug 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was a leftover from debugging. Nice catch, thanks!

@cvium
Copy link
Copy Markdown
Contributor

cvium commented Aug 13, 2016

Other than some PEP8 issues it looks fine.

@danielkza
Copy link
Copy Markdown
Contributor Author

Would it be preferable to fix the issues in an extra commit or just amend the previous ones?

@liiight
Copy link
Copy Markdown
Member

liiight commented Aug 14, 2016

Another commit is fine

@danielkza
Copy link
Copy Markdown
Contributor Author

Done.

@danielkza
Copy link
Copy Markdown
Contributor Author

I don't know what's wrong with Codacy, it shows no issues with the commit but fails anyway.

@cvium
Copy link
Copy Markdown
Contributor

cvium commented Aug 15, 2016

We had miscommunication so our codacy account got deleted along with its config. We have yet to reconfigure the new one.

@cvium cvium merged commit 95c762f into Flexget:develop Aug 15, 2016
@danielkza
Copy link
Copy Markdown
Contributor Author

I update the Wiki page with the new additions. Thanks a lot!

@danielkza danielkza deleted the subliminal-improvements branch August 15, 2016 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants