XZise created this task.
XZise added a subscriber: XZise.
XZise added a project: pywikibot-core.
Restricted Application added subscribers: Aklapper, pywikipedia-bugs.
TASK DESCRIPTION
As the overall trend should be towards using AutoFamily I want to list everything which
looks unnecessary as it can be fetched via the API here.
The following could be replaced by API calls:
* `namespacesWithSubpage`: This should be already possible via the `Namespace` class, as
it's in
[[
https://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&sipr…]]
returned as `subpages=""`. Maybe the Namespace class should get properties like
`has_subpages` which make it easier to use.
* `linktrails` and `linktrail()`: At least in newer wikis it is reported via the API
[[
https://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&sipr…]]
although I'm not sure how much a “MediaWiki:Linktrail” does change/overwrite it. Main
problem there is to parse it into a Python regex (see also
[[
https://gerrit.wikimedia.org/r/184216/|Gerrit 184216]])
* `known_families` and `get_known_families()`: Could be replaced by using the interwiki
map. There is only one usage in the library which could be easily replaced.
* `nocapitalize`: This is namespace specific and already represented in the `Namespace`
class (see `Link.parse`). The primary use of it, is when creating a APISite instance that
the username is not capitalized. But according to
[[
https://www.mediawiki.org/wiki/Manual:$wgCapitalLinkOverrides|Manual:$wgCap…]]
the User namespace is never affected by that (and thus always False).
* `interwiki_forward` and `interwiki_forwarded_from`: This is can be done via the API to
determine to which project `en` for
example redirects (on commons for example to the Wikipedia).
* `obsolete`: This is an odd beast with an ambiguous definition. There is a patch to
make it obsolete [[
https://gerrit.wikimedia.org/r/187358/|Gerrit 187358]].
* `languages_by_size`: There is a patch, but that only works for some families
efficiently. There is also a patch to do that manually which would work on any but is
relatively slow as it needs to contact every code.
* `protocol()`: The AutoFamily automatically defines it. Maybe there should be a simpler
approach which just reads a `use_https` boolean attribute. So whenever someone needs a
normal Family class they can use `use_https = True`. Alternatively
`generate_family_file.py` should add that always (and then with the correct defined
protocol from the URL) so the user easily sees what needs to be done.
* `ignore_certificate_error()`: Should be similar when a normal Family class is used
(boolean attribute and `generate_family_file` does add it correctly set)
* `scriptpath()`: Is in the siteinfo (like the linktrail) but obviously to get to the
API that needs to be defined. AutoFamily (with the complete URL) already supply it.
* `versionnumber()` and `version()`: These is already deprecated, and if it needs to be
configured, `force_version()` should be used.
* `shared_image_repository()`: There is a patch
([[
https://gerrit.wikimedia.org/r/181416/|Gerrit 181416]]) to make it more dynamic, but
unfortunately it doesn't work always, so there is still some dynamic configuration
needed.
* `shared_data_repository()`: There is already a bug report here (TODO: get ID) and
depends on how multiple repositories are represented in the future.
* `server_time()`: Already deprecated with a site method.
There also some configuration variables. These should be moved into config2.py with a
“global default” a possibility to overwrite it for each family with a specific setting.
One problem could be when they need to be dynamic and executable code.
* `interwiki_attop`
* `interwiki_on_one_line`
* `interwiki_text_separator`
* `category_attop`
* `category_on_one_line`
* `category_text_separator`
* `categories_last`
* `interwiki_putfirst`
* `interwiki_putfirst_doubled`
* `ssl_pathprefix()`: Although it depends on how the siteinfo then changes, it could be
retrieved from there (same problem as `scriptpath()`).
* `nicepath()`
* `rcstream_host()`
* `_get_path_regex(self)`: That needs to change especially if a site is accessible via
multiple hostnames or it should be never defined.
* `maximum_GET_length()`
* `force_version()`
* `code2encoding()` and `encoding()`: It depends what encoding is meant. The
communication with the server on HTTP level? If so shouldn't the server answer
accordingly if there is no valid encoding. It could then use that encoding. If it is
really required (and not UTF-8) we could still implement it via a configuration variable.
* `post_get_convert()` and `pre_put_convert()`: This should be probably rewritten into a
list of converters and then via a configuration some converters could enabled.
Some of the methods are static and don't need to be changed/overwritten and thus
don't need to be removed:
* `language_groups`: Although this could be probably statically defined and doesn't
change with other families
* `hostname()` and `ssl_hostname()`: Those are set correctly in AutoFamily and the
question is, if they need to be overridden in normal Family instances.
* `path()`, `querypath()`, `apipath()`, `nice_get_address()`: Those probably never
change and are always relative to `scriptpath()`/`nicepath()`
* `from_url()`
I'm not sure about these however:
* `category_redirect_templates`, `category_redirects()`, `get_cr_templates()`
* `use_hard_category_redirects`
* `disambiguation_templates`, `disambig()`
* `cross_projects`
* `cross_projects_cookies`
* `cross_projects_cookie_username`
* `cross_allowed`
* `disambcatname`
* `ldapDomain`
* `crossnamespace`
* `iw_keys()`: This basically list all codes and the codes of from `interwiki_forward`.
Could be probably replaced by a better interwiki map implementation which allows to get
the complete mapping (instead of the current way to get only one definition).
* `_addlang()`
* `dbName()`
* `code2encodings()` and `encodings()`: Those two are somewhat strange, because they
return by default the same value as the singular variants (not even wrapping them in a
list). But even then why does it need to define multiple encodings?
* `isPublic()`
TASK DETAIL
https://phabricator.wikimedia.org/T89451
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
<username>.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: XZise
Cc: pywikipedia-bugs, Aklapper, XZise, jayvdb