By default, only updates that are propagated trough the Fedora's update system
will be available in the community Copr build system.
On stable Fedora releases,
updates (including new packages) might be delayed 1+ week.
This adds the latest Koji (that's the name of the official Fedora build system) repo.
That repo contains more recent packages available during the official Fedora builds.
The Koji repo is not mirrored,
so the Copr builds are more likely to encounter a network issue,
but I think it is worth it.
The `/packit build` command may be used in the pull request if this happens.
* Support `requests.response.raw` being a file-like object
Previously HTTPie relied on `requests.models.Response.raw` being
`urllib3.HTTPResponse`. The `requests` documentation specifies that
(requests.models.Response.raw)[https://docs.python-requests.org/en/master/api/#requests.Response.raw]
is a file-like object but allows for other types for internal use.
This change introduces graceful handling for scenarios when
`requests.models.Response.raw` is not `urllib3.HTTPResponse`. In such a scenario
HTTPie now falls back to extracting metadata from `requests.models.Response`
directly instead of direct access from protected protected members such as
`response.raw._original_response`. A side effect in this fallback procedure is
that we can no longer determine HTTP protocol version and report it as `1.1`.
This change is necessary to make it possible to implement `TransportPlugins`
without having to also needing to emulate internal behavior of `urlib3` and
`http.client`.
* Load cookies from `response.headers` instead of `response.raw._original_response.msg._headers`
`response.cookies` was not utilized as it not possible to construct original
payload from `http.cookiejar.Cookie`. Data is stored in lossy format. For example
`Cookie.secure` defaults to `False` so we cannot distinguish if `Cookie.secure` was
set to `False` or was not set at all. Same problem applies to other fields also.
* Simpler HTTP envelope data extraction
* Test cookie extraction and make cookie presentment backwards compatible
Co-authored-by: Mickaël Schoentgen <contact@tiger-222.fr>
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
* Make sure there’s no trailing \n in test files for easier output inspection
* Refactor output matching test utils
* More robust `test_http_307_allow_redirect_post_verbose()`
* Changelog
* Mention HTTP 307 Temporary Redirect re-post behaviour in README
Running tests through `python setup.py test` is deprecated:
> WARNING: Testing via this command is deprecated and will be removed
> in a future version. Users looking for a generic test entry point
> independent of test runner are encouraged to use tox.
I am not in favor of moving back to `tox`, we should simply run tests
using `python -m pytest` (or `make test`) and that's it.
A new extra was added, `dev`, to install development requirements:
$ python -m pip install --upgrade --editable '.[dev]'
The fix may actually be slightly more complex than I expected.
We would need, at first sight, to loose the prepared requests + responses streaming.
A potential solution will come in a near future.
https://docs.python.org/3.10/whatsnew/3.10.html#enum
Python 3.10 changed the repr of enum members, and the doctest of tests.utils.http failed.
Exact reprs are unfortunately not considered stable API between Python releases:
=================================== FAILURES ===================================
__________________________ [doctest] tests.utils.http __________________________
209
210 Example:
211
212 $ http --auth=user:password GET pie.dev/basic-auth/user/password
213
214 >>> httpbin = getfixture('httpbin')
215 >>> r = http('-a', 'user:pw', httpbin.url + '/basic-auth/user/pw')
216 >>> type(r) == StrCLIResponse
217 True
218 >>> r.exit_status
Expected:
<ExitStatus.SUCCESS: 0>
Got:
ExitStatus.SUCCESS
A simple replacement of the expected output however breaks the doctest on Python 3.9.
This is the best solution I could think of
that keeps the docstring readable and doctest working in Pythons both old and new.
Since `python setup.py test` is deprecated and `tests_require` is only used by that,
this allows to programmatically read the tests dependencies from the metadata.
The default value already contains this,
but when setting a custom one, it was overridden.
In Fedora, we build the package in `.pyproject-builddir` and not ignoring it confuses pytest:
_pytest.pathlib.ImportPathMismatchError: ('httpie.__main__', '/builddir/build/BUILD/httpie-2.4.0/.pyproject-builddir/pip-req-build-aedma65c/build/lib/httpie/__main__.py', PosixPath('/builddir/build/BUILD/httpie-2.4.0/.pyproject-builddir/pip-req-build-aedma65c/httpie/__main__.py'))
* Add --raw to allow specifying the raw request body without extra processing
As an alternative to `stdin`.
Co-authored-by: Elena Lape <elapinskaite@gmail.com>
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
* Update README.rst
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
* Update README.rst
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
* Fix default HTTP method on empty data
Co-authored-by: Elena Lape <elapinskaite@gmail.com>
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
* Prefer usage of "python -m pip" instead of "pip"
It will prevent issues when users think that they are using
the correct `pip` version. It can refers to the one from the OS
Python installation, or even worse to a Python 2 installation.
Let's be clear on how to install stuff.
Also used short version of `pip` arguments, because we are all lazy :)
* Apply suggestions from code review
`py.test` was chosen over `pytest` but it is not planned for removal yet [1].
Anyway, it is a good thing to ensure we are using the correct Python version
with the right `pytest` installed, so using `python -m pytest` is recommended.
[1] https://github.com/pytest-dev/pytest/issues/1629
