100%, baby

Signed-off-by: Adam Williamson <awilliam@redhat.com>

This fallback seems broken and weird. I can't see why:

1) We do it at all
2) Given that we do it, we do it only for namespace IDs in
   site.namespaces

It's existed since the first version of mwclient, but I really
can't see how it's valid. A `Site` instance's `self.namespaces`
starts out as `default_namespaces`, then in `site_init`, we read
in the real namespace configuration of the specific wiki. If the
wiki changes the default namespaces, we should respect that. So
it seems to me we should just trust `self.namespaces`. I don't
see how any kind of fallback to `self.default_namespaces` is ever
going to give a more useful result than not doing it.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

This covers missing statements in the PageList class.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

This covers some uncovered statements in the Category class.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

I had to invent the API response because this is only used for
the CheckUser extension and I don't have enough privileges to
actually use that extension on any wiki with it installed, but
I'm pretty sure this more or less captures what it's meant to do.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

This covers the `List.__repr__` method.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

This covers the `if self.result_member not in data['query']`
branch of `set_iter`.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

new-style continuation is available since 1.21, and we are
already forcing it for mw 1.21-1.25 in `api` by adding `continue`
to kwargs if it's not there. Old-style continuation is only
available by passing `rawcontinue=` and is not recommended.
I don't think we need to maintain support for it in the List
class. Theoretically it could maybe still be used if someone is
passing `rawcontinue=""` as an arg to `List` or a subclass of it
(and that overrides the `continue=` that we force in - I'm not
sure which wins), but I can't imagine why anyone would want to do
that.

This improves test coverage because old-style continuation is
uncovered at present. I'd rather remove it than write a test for
it.

See: https://www.mediawiki.org/wiki/API:Continue



Signed-off-by: Adam Williamson <awilliam@redhat.com>

This covers the `if not data: raise StopIteration` bit of
`load_chunk`.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

Signed-off-by: Adam Williamson <awilliam@redhat.com>

made 429 Too Many Request HTTP error in raw_call() retryable

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5.1.1 to 5.2.0.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v5.1.1...v5.2.0

)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

This adds an integration test that runs a set of mediawiki
containers, configures them enough that the API works, then runs
a few simple tests of logging in, creating, moving and deleting
pages. We also enable this in CI. We can extend this with more
tests later, I think this is a reasonable initial set.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

3.12 is current now.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

That's the current stable Python.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

The setup.py test command and pytest-runner have been deprecated for
several years and are no longer recommended. The pytest documentation
no longer recommends pytest-runner and their own documentation
recommends against it.

- https://github.com/pypa/setuptools/issues/1684
- https://github.com/pytest-dev/pytest/issues/5534
- https://github.com/pytest-dev/pytest-runner/issues/50

Changes made:

- Removed pytest-runner: Eliminated the use of pytest-runner from
  `setup.py`.
- Moved test dependencies to the `extra-dependencies`, which can be used
  by tox as well as for manual installation.
- Updated the documentation to recommend using tox as the default test
  runner. Alternatively, users can manually run tests with the `py.test`
  command.

These changes will also make an eventual migration to `pyproject.toml`
easier, as the `extras_require` can be copied to the
`project.optional-dependencies` section.

I found this while writing integration tests. If you try to login
with an incorrect username and password, mwclient correctly raises
mwclient.errors.LoginError...but if you then check logged_in, it
is True. Clearly that's wrong.

The logic for setting logged_in will basically consider us logged
in any time we process an API call and there is no 'anon' key in
the userinfo dict *or there is no userinfo dict at all*. The last
API call processed on a failed login attempt has no userinfo
dict.

This tweaks it so we only changed the logged_in value (in either
direction) if the API call we're handling has a userinfo dict.

We also fix the type of the empty userinfo we create if there
isn't one in the call (no idea why it was a tuple, it doesn't
really matter but it's weird) and explicitly set self.logged_in
to False in Site initialization. I don't think this is strictly
necessary as we can expect the init process to result in at least
one API call with a userinfo dict, but it feels more correct.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

- Removed the unnecessary try/catch block around the get_token call. The
  code would already have thrown an exception earlier if the site was
  uninitialized, making this block redundant.
- Eliminated the while True loop, as every branch of the loop had a
  return statement, preventing it from executing more than once.
- Replaced outdated printf-style string formatting with str.format().
- Renamed the `login` variable to `response`

This fix ensures that the `Site` object is properly initialized after a
successful `Site.clientlogin`, matching the existing behavior of
`Site.login()`.

Previously, developers needed to manually invoke `Site.site_init()`
after using `clientlogin`, which could lead to unexpected issues,
especially during migration from `login` to `clientlogin`.

For example, the following code works with `Site.login`:

```python
site = mwclient.Site('localhost:8080', path='/', scheme='http')
site.login('username', 'super-secret')
with open('/tmp/image.png', 'rb') as f:
    site.upload(f, 'image.png', 'Some test upload', ignore=True)
```

But when using `Site.clientlogin` without this fix, the code would fail
with `mwclient.errors.InsufficientPermission: image.png`:

```python
site = mwclient.Site('localhost:8080', path='/', scheme='http')
site.clientlogin(username='username', password='super-secret')
with open('/tmp/image.png', 'rb') as f:
    site.upload(f, 'image.png', 'Some test upload', ignore=True)
```

Replaced the dynamic JSON string construction with a direct dictionary
definition for namespaces.

This commit refactors the codebase to consistently use Python 3.6
f-strings for string concatenation and interpolation.

BREAKING CHANGE: This update increases the minimum required Python
version from 3.5 to 3.6. Python 3.5 reached end-of-life in September
2020 (~4 years ago) and has been dropped from most distributions, so the
impact on users should be minimal.

This commit updates some outdated syntax with the modern alternatives.
The changes were applied automatically using pyupgrade (v2.0.1) with the
following command:

```
pyupgrade --py3-plus **/*.py
```

These updates are purely syntactical and there should be no change in
functionality.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

Signed-off-by: Adam Williamson <awilliam@redhat.com>

As discussed in #259, the `limit` parameter - to the low-level
`listing.List` and its subclasses, and to various higher-level
functions which ultimately return `List` or `GeneratorList`
instances - is confusing and misleading.

It is passed through to the API calls, and effectively specifies
how many items a single API call will return. But because our
`List` yields a single item at a time and will keep doing API
calls until the API says there's no more data, it does not limit
how many items our `List` will yield, nor specify its chunk size.
It seems natural to expect that `List(limit=10)` or
`page.revisions(limit=10)` will give you a generator that yields
only 10 items, or yields 10 items at a time, but it does not; it
gives you a generator which queries the API in chunks of 10 items
at a time, but will yield every item the API gives it, one by one.

This is probably not ever how we really intended mwclient to work
(there's an old `# NOTE: Fix limit` comment which implies as much)
but it has worked this way for 16 years, so we should probably
not change it just in case someone really has a need to specify
the API chunk size for some reason, or some code somehow happens
to implicitly rely on it behaving the way it does.

So, this keeps the behaviour of the `limit` param wherever it
exists, but triggers a deprecation warning. Everything that had
a `limit` param now also has an `api_chunk_size` param that does
the same thing, but is more explicitly named and does not trigger
a deprecation warning. And everything that had a `limit` param
now also has a `max_items` param that does what it sounds like,
and what people are more likely to want - sets an absolute limit
on the number of items the generator will yield.

For efficiency, if `max_items` is set, neither `limit` nor
`api_chunk_size` is set, and `max_items` is below
`site.api_limit`, we set the API chunk size to `max_items` so
we only retrieve as many items as we actually need.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

writeapi is being removed

Bug: T294397

Raises an error when ignore=False and the MediaWiki response contains
the `upload.warnings.exists` key. Previously, this warning was logged,
but the call to `Site.upload` succeeded. This could be easily missed by
users, especially when they haven't configured the log level.

As discussed in #197, this renames the `reqs` argument to `Site`
to `connection_options`. The old name still works but triggers a
DeprecationWarning. If you specify both we raise ValueError.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

Bumps [sigstore/gh-action-sigstore-python](https://github.com/sigstore/gh-action-sigstore-python) from 2.1.1 to 3.0.0.
- [Release notes](https://github.com/sigstore/gh-action-sigstore-python/releases)
- [Changelog](https://github.com/sigstore/gh-action-sigstore-python/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sigstore/gh-action-sigstore-python/compare/v2.1.1...v3.0.0

)

---
updated-dependencies:
- dependency-name: sigstore/gh-action-sigstore-python
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5.1.0 to 5.1.1.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v5.1.0...v5.1.1

)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

This is the one from
https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/


again, with an `if` condition added and multilines rewrapped. As
best as I can tell, this should work automagically, we don't need
to "sign up for" sigstore or create any certificates or keys; it
works by creating an ephemeral signing certificate bound to the
identity of whatever GitHub user the workflow runs as (proved by
OIDC), and signing with that.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

The tarballs from current releases have these files in them, but
building with `build` does not include them. I don't know if the
previous maintainer was using setuptools-scm or something like
that, but this should ensure that appropriate files are included
in our new tarballs. I left out things like .gitattributes which
clearly shouldn't be in a release tarball.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

Signed-off-by: Adam Williamson <awilliam@redhat.com>

This is based on
https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#defining-a-workflow-job-environment
. It's the sample config from there, with versions updated and
our project name substituted in the appropriate places. I dropped
the publish-to-testpypi bit because of
https://github.com/pypa/packaging.python.org/issues/804

 , and left
the Github release part left out for now. We can add that later if
we like, but we never published releases to Github before, so it
doesn't seem required yet. I also tweaked the conditionals a bit
to avoid running the build job on forks and publish only tags
that start with 'v', as that's our convention for versions.

Signed-off-by: Adam Williamson <awilliam@redhat.com>