Is there anything left to do here?

followlive was archived. Please reopen this Task if you still using this script. Also create a new task to restore the archived script.

We already have a -grep filter. This will work together with any generator e.g. with -start. There is not such -match filter on API side which can be used.

flickrripper is archived. If you still use that script, please reopen this task and create another to restore the archived script to the actively maintained scripts

Already done via -autosummary option
See: https://www.mediawiki.org/wiki/Autosummary

In T223816#7162095, @Mh-3110 wrote:

The remaining request is not implementable at the current state of the software.
Thanks

There is a follow-up patch to decreate the requirents:
https://gerrit.wikimedia.org/r/c/pywikibot/core/+/700163

Already solved

I reopend it and revert the check script check (until 7.0 or so). I think setuptools can be updatet on toolforge with virtualenv but I am not sure.

The ticket is T283565. But I propose to keep the old script and have renamed it. Is was created for the compat to core migration, is very simple, doesn’t use AST but works good enough.

In T281202#7130863, @atagar wrote:

I amended our deprecation policy in the following ways...

1. Copy the description of semantic versioning I wrote for Tor. We now explain what version numbers convey in terms of backward compatibility.
2. Drop the description of DeprecationWarnings vs FutureWarnings.
3. Drop the "Deprecations might be expedited when necessary" clause. If we break backward compatibility we should bump our major version number.
4. State that prior to version 6.3.1 we did not use any particular versioning scheme since we haven't been following semantic versioning's policy for code removal.

Xqt, would you mind taking a look? To be very clear if we adopt this policy we should do the following...

1. All deprecated code will be removed upon Pywikibot 7.0.0.
2. No deprecated code will be removed until then. This includes code deprecated all the way back in 3.1.

We tried this already with "rebase if necessary" action [1] but got problems with the local repository where the patches were no longer in sync with the repository.
Rebase is not necessary if you have not merge conflict but it is also necessary in case of cherry-pick action and a merge conflict ocurres. Much more important is that cherry-pick action does not respect dependencies between patches.

In T284577#7148157, @ChrisBlomTS wrote:

It doesn't, the mw_version check in api.Request.add_defaults() (line 1243) still fails.

I think the problem is the api.LoginManager.login_to_site code part. No further api calls should be necessary before login is either successfull or denied. A try/except clause instead of mw_version test should be made here

In T120024#6501532, @Shubham656jain wrote:

Hi. If the issue is not taken, I'd like to contribute in it? Please reply!

@Ngwebecky96: are you still working on this?

Since rPWBCcaca33889b09: [IMPR] Throttle requests after ratelimits exceeded (3.0.20200609), you should see a warning with No rate limit found for action <action> if you get rate limited but ratelimits doesn't have a rate limit. This warning is missing from the report.

In T277396#7125020, @atagar wrote:

Hi Xqt. It's a bit unclear to me what the task is...

lint checker that would look at the function's signature (i.e. parameter names) and compares with the function documentation

Does this mean this aims for a lint check for the following?

def my_function(my_arg):
  """
  Some neat stuff.

  :param wrong_name: blah
  """

If so I'd be happy to take a look, but I'd think Sphinx would already exhibit a warning for that.

@atagar: are you willing to takeover this task?

See also T103779. Probably a good idea to circumvent the <option>:not problem.

Seems` config.retry_wait` is set to 0 and there is no ratelimit given for the current user.

In T278046#7122672, @atagar wrote:

Don't see any advantage.

Isn't the advantage that epytext is unmaintained as of 2008 and reSt is the documentation format most python projects use? For my part I've extensively worked with Sphinx's reSt whereas pywikibot is the first time I've ever seen epytext. It would be nice for pywikibot newcomers not to need to learn an obsolete documentation format unless we have significant reason to do so.

Ok that might be a good reason to switch completey. I am fine with it. Sphinx is already supported and there is only the Link shortener which can be useful. The conversion is made in` conf.pywikibot_epytext_to_sphinx()` function.