Commits on Source (65)
-
Adam Williamson authored
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>
-
Marc Troelitzsch authored
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.
-
lilydjwg authored
-
Andrew Bogott authored
writeapi is being removed Bug: T294397
-
Andrew Bogott authored
-
Adam Williamson authored
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>
-
Adam Williamson authored
Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
-
Marc Troelitzsch authored
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.
-
Marc Troelitzsch authored
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.
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
Replaced the dynamic JSON string construction with a direct dictionary definition for namespaces.
-
Marc Troelitzsch authored
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) ```
-
Marc Troelitzsch authored
- 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`
-
Adam Williamson authored
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>
-
Marc Troelitzsch authored
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.
-
Adam Williamson authored
That's the current stable Python. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
3.12 is current now. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
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>
-
dependabot[bot] authored
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>
-
Vladislav Suchkov authored
made 429 Too Many Request HTTP error in raw_call() retryable
-
Adam Williamson authored
Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
This covers the `if not data: raise StopIteration` bit of `load_chunk`. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
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>
-
Adam Williamson authored
This covers the `if self.result_member not in data['query']` branch of `set_iter`. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
This covers the `List.__repr__` method. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
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>
-
Adam Williamson authored
This covers some uncovered statements in the Category class. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
This covers missing statements in the PageList class. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
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>
-
Adam Williamson authored
100%, baby Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
In the examples in the MediaWiki documentation, versions are compared using the `version_compare` function from the PHP standard library: https://www.mediawiki.org/wiki/Manual:$wgVersion#Example_code Before comparison, this version canonicalizes version strings according to the following rules: - Replace _, - and + with a dot . - Insert dots . before and after any non number This commit updates `Site.version_tuple_from_generator` to parse versions according to those rules.
-
Marc Troelitzsch authored
Non-integers in these positions would lead to issues when comparing versions, e.g. `self.version[:2] > (1, 27)`.
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
The logic for this was removed in cd4830a5, seems like the error was forgotten at the time.
-
Marc Troelitzsch authored
Previously only `mwclient.errors.InsufficientPermission` was included
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
-
Marc Trölitzsch authored
-
Marc Troelitzsch authored
Renaming `types.py` to `_types.py` to avoid conflicts with Python's built-in modules. This change addresses some `ImportErrors` such as: ``` ImportError: cannot import name 'MappingProxyType' from partially initialized module 'types' (most likely due to a circular import) ``` As far as I can tell this is not a problem when installing the library using pip or running tests in tox, only local execution when adding the source-root to the `PYTHONPATH`. This is e.g. the case in the default IntelliJ/Pycharm run configuration when testing in scratch files.
-
Marc Troelitzsch authored
-
Marc Trölitzsch authored
-
NDKDD authored
-
NDKDD authored
-
NDKDD authored
-
NDKDD authored
-
NDKDD authored
-
Marc Troelitzsch authored
To keep build-compatibility with Python 3.6, I've switched the build backend from `setuptools` to `hatchling`. `setuptools` only supports `pyproject.toml` from version 61 onwards, which itself isn't compatible with Python 3.6. This does not mean we have to fully use Hatch as we can still create build using `python -m build`. Hatchling automatically includes all non-gitignored files, so the `MANIFEST.in` file has been removed.
-
Marc Troelitzsch authored
The flake8 section is the only one left, so might as well rename the file.
-
Marc Troelitzsch authored
ubuntu-latest is in the process of being updated from ubuntu-22.04 to ubuntu-24.04, which leads to issues with py37: ``` Version 3.7 was not found in the local cache Error: The version '3.7' with architecture 'x64' was not found for Ubuntu 24.04. ``` This commit hard-codes the ubuntu-version for py37 to ubuntu-22.04, similar to what we've done for py36. See https://github.com/actions/runner-images/issues/10636 for more information.
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
This change replaces the deprecated `pkg_resources` (part of `setuptools`) with `importlib.metadata` for Python 3.8 and above. Switching to `importlib.metadata` allows us to drop the test-dependency on `setuptools` and gets rid of the `DeprecationWarning` raised by certain versions of `pkg_resources` when being imported: ``` DeprecationWarning: pkg_resources is deprecated as an API ```
-
Marc Troelitzsch authored
These options had been removed in 96dea321. They were (accidentally) re-added in #360 (859f3eec).
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
Refactored `Site.expandtemplates` to use the updated API, addressing deprecation warnings in recent MediaWiki versions. The older API triggered the following warnings: ``` WARNING:mwclient.client:Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes. Use [[Special:ApiFeatureUsage]] to see usage of deprecated features by your application. WARNING:mwclient.client:The parameter "generatexml" has been deprecated. Because "prop" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used. ```
-
Marc Troelitzsch authored
closes #128
-
dependabot[bot] authored
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5.2.0 to 5.3.0. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](https://github.com/actions/setup-python/compare/v5.2.0...v5.3.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>
-
dependabot[bot] authored
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5.3.0 to 5.4.0. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](https://github.com/actions/setup-python/compare/v5.3.0...v5.4.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>
-
Dylann Cordel authored
Showing
- .flake8 1 addition, 4 deletions.flake8
- .github/workflows/integration.yml 28 additions, 0 deletions.github/workflows/integration.yml
- .github/workflows/release.yml 1 addition, 1 deletion.github/workflows/release.yml
- .github/workflows/tox.yml 7 additions, 4 deletions.github/workflows/tox.yml
- .gitignore 1 addition, 0 deletions.gitignore
- .readthedocs.yaml 4 additions, 3 deletions.readthedocs.yaml
- CREDITS.md 6 additions, 1 deletionCREDITS.md
- MANIFEST.in 0 additions, 11 deletionsMANIFEST.in
- README.md 12 additions, 3 deletionsREADME.md
- docs/requirements.txt 0 additions, 2 deletionsdocs/requirements.txt
- docs/source/conf.py 4 additions, 2 deletionsdocs/source/conf.py
- docs/source/development/index.rst 94 additions, 25 deletionsdocs/source/development/index.rst
- docs/source/index.rst 20 additions, 4 deletionsdocs/source/index.rst
- docs/source/reference/errors.rst 4 additions, 2 deletionsdocs/source/reference/errors.rst
- docs/source/user/connecting.rst 2 additions, 2 deletionsdocs/source/user/connecting.rst
- docs/source/user/implementation-notes.rst 1 addition, 1 deletiondocs/source/user/implementation-notes.rst
- docs/source/user/page-ops.rst 1 addition, 1 deletiondocs/source/user/page-ops.rst
- examples/basic_edit.py 12 additions, 12 deletionsexamples/basic_edit.py
- examples/upload.py 3 additions, 3 deletionsexamples/upload.py
- mwclient/__init__.py 1 addition, 1 deletionmwclient/__init__.py
.github/workflows/integration.yml
0 → 100644
MANIFEST.in
deleted
100644 → 0
docs/requirements.txt
deleted
100644 → 0