Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Aug 22, 2024
    • Marc Troelitzsch's avatar
      fix: Automatically initialize `Site` after successful `clientlogin` · 78006fc7
      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)
```
      78006fc7
  3. Aug 21, 2024
  5. Aug 11, 2024
    • Adam Williamson's avatar
      Bump version: 0.10.1 → 0.11.0 · da48d446
      Adam Williamson authored
      da48d446
    • Adam Williamson's avatar
      Update bumpversion config to avoid incorrect replacement · a6bf6aa9
      Adam Williamson authored 
      
Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      a6bf6aa9
    • Adam Williamson's avatar
      Update CREDITS.md ahead of the new release · a1895931
      Adam Williamson authored 
      
Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      a1895931
    • Adam Williamson's avatar
      Deprecate `limit` for `api_chunk_size`, extend `max_items` (#259) · 95c0b0fc
      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: default avatarAdam Williamson <awilliam@redhat.com>
      95c0b0fc
  7. Aug 08, 2024
  9. Jul 17, 2024
  11. Jul 16, 2024
  13. Jul 11, 2024
  15. Jun 01, 2024
  17. May 18, 2024
  19. May 06, 2024
  21. Mar 27, 2024
  23. Feb 16, 2024
  25. Feb 09, 2024
  27. Jan 28, 2024
  29. Jan 27, 2024
  31. Dec 07, 2023