- Sep 01, 2024
-
-
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 not data: raise StopIteration` bit of `load_chunk`. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
- Aug 31, 2024
-
-
Vladislav Suchkov authored
made 429 Too Many Request HTTP error in raw_call() retryable
-
- Aug 30, 2024
-
-
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>
-
- Aug 26, 2024
-
-
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>
-
Adam Williamson authored
3.12 is current now. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
That's the current stable Python. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
- Aug 25, 2024
-
-
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.
-
- Aug 23, 2024
-
-
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>
-
- Aug 22, 2024
-
-
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`
-
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) ```
-
- Aug 21, 2024
-
-
Marc Troelitzsch authored
Replaced the dynamic JSON string construction with a direct dictionary definition for namespaces.
-
Marc Troelitzsch authored
-
Marc Troelitzsch authored
-
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
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.
-
- Aug 11, 2024
-
-
Adam Williamson authored
-
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
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>
-
- Aug 08, 2024
-
-
Andrew Bogott authored
-
Andrew Bogott authored
writeapi is being removed Bug: T294397
-
- Jul 17, 2024
-
-
lilydjwg authored
-
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.
-
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>
-
- Jul 16, 2024
-
-
dependabot[bot] authored
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>
-
- Jul 11, 2024
-
-
dependabot[bot] authored
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>
-
- Jun 01, 2024
-
-
Adam Williamson authored
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>
-
- May 18, 2024
-
-
Adam Williamson authored
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>
-
Adam Williamson authored
Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
- May 06, 2024
-
-
Marc Troelitzsch authored
-
Adam Williamson authored
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>
-
Adam Williamson authored
The latest incarnation of bumpversion is bump-my-version, which considers .cfg configuration "deprecated" and wants it moved to TOML, so here we go. We may as well move pytest config at the same time as pytest has supported it for ages. We can drop the "universal wheel" thing as that was about supporting Python 2 and 3 in the same wheel, and we don't support Python 2 any more. flake8 does not support pyproject.toml and it doesn't look like you can specify aliases for setup.py there either, so we'll leave those two in setup.cfg for now. Maybe in future we can get rid of them. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
It's much nicer to have the main repo as origin and your fork as another remote you just push PR branches to. That way you don't have to deal with resyncing the master branch of your fork all the time. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
- Mar 27, 2024
-
-
Marc Troelitzsch authored
-
dependabot[bot] authored
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5.0.0 to 5.1.0. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](https://github.com/actions/setup-python/compare/v5.0.0...v5.1.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>
-
- Feb 16, 2024
-
-
Adam Williamson authored
They were for an entirely different project. Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-
Adam Williamson authored
Signed-off-by:
Adam Williamson <awilliam@redhat.com>
-