XZise added a comment.
Okay in https://phabricator.wikimedia.org/rPWBCd6b6e4b37a33f4aafb418a5d44769e1cf53a… I added that the complete version number must match a certain scheme. You commented there:
> There are also 'official' distro releases with their own generator suffix, which we 'should' support, or at least track which cases currently fail, and have TODO's for any important cases which are not handled correctly.
>
> https://wikiapiary.com/wiki/Generator:Generators/DEBIANhttps://wikiapiary.com/wiki/Generator:Generators/CUSTOM
So it seems this is on of those cases. If there is a sensible scheme behind this we could add it but what if it's 1.19.20 with backported features from newer versions? There is no sensible match then (except for the lowest common denominator). Also the docstring of `force_version` specifically says that it can be used for that:
The site is usually using the version number from the servers'
siteinfo, but if there is a problem with that it's possible to return
a non-empty string here representing another version number.
(I just noticed it should be server's)
So for now I can only suggest to add the capability to return a callable which converts a incompatible version number in a compatible one (so that it's at least somewhat flexible).
TASK DETAIL
https://phabricator.wikimedia.org/T96813
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: XZise, jayvdb, Aklapper, pywikipedia-bugs
XZise added a subscriber: XZise.
XZise added a comment.
As a workaround `force_version` could be used. Otherwise please … how do we want to handle that version? Is that 1.19.20 (so 1.19.21 is newer?) and discard the rest? I know that I've worked on changing this and afaik added that it's not allowing such weird versions but mostly because there is no sensible way in interpreting such a version number.
TASK DETAIL
https://phabricator.wikimedia.org/T96813
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: XZise, jayvdb, Aklapper, pywikipedia-bugs
jayvdb created this task.
jayvdb added subscribers: Evanontario, jayvdb, pywikipedia-bugs, Jsalsman, Halfak.
jayvdb added a project: pywikibot-core.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
wikiwho currently depends on https://bitbucket.org/halfak/wikimedia-utilities , which is great at xml dump processing , with limited API support.
it would be useful to integrate wikiwho with pywikibot to work on live revisions from the wiki.
TASK DETAIL
https://phabricator.wikimedia.org/T89763
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: jayvdb
Cc: Halfak, Jsalsman, jayvdb, Aklapper, Evanontario, pywikipedia-bugs
jayvdb created this task.
jayvdb claimed this task.
jayvdb added subscribers: pywikipedia-bugs, valhallasw, siebrand, Nemo_bis, jayvdb.
jayvdb added projects: Pywikibot-i18n, i18n.
TASK DESCRIPTION
JSON files have been added to pywikibot/i18n, which now has python and JSON files with the same messages. The JSON files are not used yet, as the code changes to enable JSON have exposed packaging problems that are the subject of RFC https://www.mediawiki.org/wiki/Requests_for_comment/pywikibot_2.0_packaging
We need syntax validation of these JSON files for gerrit submissions, as message changes typically need to be approved quickly (and without errors) so they can be merged and the core & compat i18n submodule updated, before the messages can be used in code changes.
TASK DETAIL
https://phabricator.wikimedia.org/T85335
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: jayvdb
Cc: Aklapper, valhallasw, siebrand, Nemo_bis, jayvdb, Gryllida, Shizhao, Arrbee, pywikipedia-bugs
jayvdb created this task.
jayvdb claimed this task.
jayvdb added subscribers: jayvdb, Legoktm, hashar.
jayvdb added projects: Continuous-Integration, pywikibot-core.
Restricted Application added subscribers: Aklapper, pywikipedia-bugs.
TASK DESCRIPTION
As jenkins will no longer automatically run rules in tox.ini, we need to hardwire pep8 and pep257 into jenkins, like the mediawiki lint tests.
pep8 runs without arguments, using the config in tox.ini for the exclude and ignore list.
pep257 doesn't have an exclude parameter (yet), but looks like they are interested in that feature:
https://github.com/GreenSteam/pep257/pull/22#issuecomment-70471875
While waiting for feedback on adding exclude to pep257, it would be nice if we didnt need an exclude list .. ;-)
date.py is being ignored by flake8, but is processed by pep257, so I've tackled that.
https://gerrit.wikimedia.org/r/#/c/185815/
pep257 is validating ez_setup.py , which I've tried to fix at the source of the problem:
https://bitbucket.org/pypa/setuptools/pull-request/117/pep8-and-pep257-comp…
pep257 doesnt ignore items with '# noqa' , so it is emitting errors for interwiki.py (easy) and pywikibot/exceptions.py (messy).
Also if the job is hardwired into jenkins, and we can only maintain one match list in tox.ini , we cant reimplement the 'mandatory docstring' list without some serious cleanup first.
TASK DETAIL
https://phabricator.wikimedia.org/T87169
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: jayvdb
Cc: hashar, Legoktm, jayvdb, Aklapper, greg, pywikipedia-bugs
jayvdb created this task.
jayvdb added subscribers: pywikipedia-bugs, jayvdb, Aklapper.
jayvdb added a project: pywikibot-core.
TASK DESCRIPTION
The lonelypages script only has a dictionary of languages, and if an entry exists in the dictionary for the site language, the script runs.
As a result of a very recent i18n change (https://gerrit.wikimedia.org/r/#/c/199579/), this means that the script runs on wikidata using the English configuration, even though this is inappropriate as the template {{Orphan}} in the English configuration is not present on that site (https://www.wikidata.org/wiki/Template:Orphan).
TASK DETAIL
https://phabricator.wikimedia.org/T94680
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: jayvdb
Cc: Aklapper, jayvdb, pywikipedia-bugs
XZise created this task.
XZise added a subscriber: XZise.
XZise added a project: pywikibot-core.
TASK DESCRIPTION
Similar to T74847 the wikibase settings are hardcoded into the family files. There is [[https://en.wikipedia.org/w/api.php?action=query&meta=wikibase|`action=query…]] which would allow to make dynamically if the API plays along. In T74847 a very nasty problem surfaced which made it at least very hard to determine the Site object parameter (basically which family and code it uses) based on the result (see T85153).
So part of this task is also to determine if this API call has the same problem so other wikibase installations in the wild should be queried (or more exact: installations which use another wikibase). At least from the result of the English Wikipedia it should be easy to get a Site object because it's possible to construct the URL similar to the interwiki map URL for which we already have an implementation.
TASK DETAIL
https://phabricator.wikimedia.org/T85331
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: Aklapper, XZise, jayvdb, pywikipedia-bugs