2019-05-14 22:35:45 +02:00
|
|
|
#
|
|
|
|
|
# spec file for package python-trio
|
|
|
|
|
#
|
2020-01-11 22:16:07 +01:00
|
|
|
# Copyright (c) 2020 SUSE LLC
|
2019-05-14 22:35:45 +02:00
|
|
|
#
|
|
|
|
|
# All modifications and additions to the file contributed by third parties
|
|
|
|
|
# remain the property of their copyright owners, unless otherwise agreed
|
|
|
|
|
# upon. The license for this file, and modifications and additions to the
|
|
|
|
|
# file, is the same license as for the pristine package itself (unless the
|
|
|
|
|
# license for the pristine package is not an Open Source License, in which
|
|
|
|
|
# case the license is the MIT License). An "Open Source License" is a
|
|
|
|
|
# license that conforms to the Open Source Definition (Version 1.9)
|
|
|
|
|
# published by the Open Source Initiative.
|
|
|
|
|
|
2019-05-14 23:28:18 +02:00
|
|
|
# Please submit bugfixes or comments via https://bugs.opensuse.org/
|
|
|
|
|
#
|
2019-05-14 22:35:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
|
|
|
|
|
%define skip_python2 1
|
|
|
|
|
Name: python-trio
|
2020-01-11 22:16:07 +01:00
|
|
|
Version: 0.13.0
|
2019-05-14 22:35:45 +02:00
|
|
|
Release: 0
|
2019-06-03 10:05:03 +02:00
|
|
|
Summary: An async/await-native I/O library
|
2019-05-14 23:28:18 +02:00
|
|
|
License: MIT OR Apache-2.0
|
2019-05-14 22:35:45 +02:00
|
|
|
Group: Development/Languages/Python
|
2019-05-14 23:28:18 +02:00
|
|
|
URL: https://github.com/python-trio/trio
|
2019-05-14 22:35:45 +02:00
|
|
|
Source: https://github.com/python-trio/trio/archive/v%{version}.tar.gz#/trio-%{version}.tar.gz
|
Accepting request 721060 from home:pgajdos
- version update to 0.12.1
Features
* If you have a `~trio.abc.ReceiveStream` object, you can now use
``async for data in stream: ...`` instead of calling
`~trio.abc.ReceiveStream.receive_some`. Each iteration gives an
arbitrary sized chunk of bytes. And the best part is, the loop
automatically exits when you reach EOF, so you don't have to check for
it yourself anymore. Relatedly, you no longer need to pick a magic
buffer size value before calling
`~trio.abc.ReceiveStream.receive_some`; you can ``await
stream.receive_some()`` with no arguments, and the stream will
automatically pick a reasonable size for you. (`#959 <https://github.com/python-trio/trio/issues/959>`__)
* Threading interfaces have been reworked:
``run_sync_in_worker_thread`` is now `trio.to_thread.run_sync`, and
instead of ``BlockingTrioPortal``, use `trio.from_thread.run` and
`trio.from_thread.run_sync`. What's neat about this is that these
cooperate, so if you're in a thread created by `to_thread.run_sync`,
it remembers which Trio created it, and you can call
``trio.from_thread.*`` directly without having to pass around a
``BlockingTrioPortal`` object everywhere. (`#810 <https://github.com/python-trio/trio/issues/810>`__)
* We cleaned up the distinction between the "abstract channel interface"
and the "memory channel" concrete implementation.
`trio.abc.SendChannel` and `trio.abc.ReceiveChannel` have been slimmed
down, `trio.MemorySendChannel` and `trio.MemoryReceiveChannel` are now
public types that can be used in type hints, and there's a new
`trio.abc.Channel` interface for future bidirectional channels. (`#719 <https://github.com/python-trio/trio/issues/719>`__)
* Add :func:`trio.run_process` as a high-level helper for running a process
and waiting for it to finish, like the standard :func:`subprocess.run` does. (`#822 <https://github.com/python-trio/trio/issues/822>`__)
* On Linux, when wrapping a bare file descriptor in a Trio socket object,
Trio now auto-detects the correct ``family``, ``type``, and ``protocol``.
OBS-URL: https://build.opensuse.org/request/show/721060
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-trio?expand=0&rev=8
2019-08-05 20:07:36 +02:00
|
|
|
BuildRequires: %{python_module astor >= 0.8}
|
2019-05-14 22:35:45 +02:00
|
|
|
BuildRequires: %{python_module async_generator >= 1.9}
|
2020-01-11 22:16:07 +01:00
|
|
|
BuildRequires: %{python_module attrs >= 19.2.0}
|
2019-05-14 22:35:45 +02:00
|
|
|
BuildRequires: %{python_module idna}
|
|
|
|
|
BuildRequires: %{python_module outcome}
|
2019-05-14 23:28:18 +02:00
|
|
|
BuildRequires: %{python_module pyOpenSSL}
|
|
|
|
|
BuildRequires: %{python_module pytest}
|
|
|
|
|
BuildRequires: %{python_module setuptools}
|
Accepting request 721060 from home:pgajdos
- version update to 0.12.1
Features
* If you have a `~trio.abc.ReceiveStream` object, you can now use
``async for data in stream: ...`` instead of calling
`~trio.abc.ReceiveStream.receive_some`. Each iteration gives an
arbitrary sized chunk of bytes. And the best part is, the loop
automatically exits when you reach EOF, so you don't have to check for
it yourself anymore. Relatedly, you no longer need to pick a magic
buffer size value before calling
`~trio.abc.ReceiveStream.receive_some`; you can ``await
stream.receive_some()`` with no arguments, and the stream will
automatically pick a reasonable size for you. (`#959 <https://github.com/python-trio/trio/issues/959>`__)
* Threading interfaces have been reworked:
``run_sync_in_worker_thread`` is now `trio.to_thread.run_sync`, and
instead of ``BlockingTrioPortal``, use `trio.from_thread.run` and
`trio.from_thread.run_sync`. What's neat about this is that these
cooperate, so if you're in a thread created by `to_thread.run_sync`,
it remembers which Trio created it, and you can call
``trio.from_thread.*`` directly without having to pass around a
``BlockingTrioPortal`` object everywhere. (`#810 <https://github.com/python-trio/trio/issues/810>`__)
* We cleaned up the distinction between the "abstract channel interface"
and the "memory channel" concrete implementation.
`trio.abc.SendChannel` and `trio.abc.ReceiveChannel` have been slimmed
down, `trio.MemorySendChannel` and `trio.MemoryReceiveChannel` are now
public types that can be used in type hints, and there's a new
`trio.abc.Channel` interface for future bidirectional channels. (`#719 <https://github.com/python-trio/trio/issues/719>`__)
* Add :func:`trio.run_process` as a high-level helper for running a process
and waiting for it to finish, like the standard :func:`subprocess.run` does. (`#822 <https://github.com/python-trio/trio/issues/822>`__)
* On Linux, when wrapping a bare file descriptor in a Trio socket object,
Trio now auto-detects the correct ``family``, ``type``, and ``protocol``.
OBS-URL: https://build.opensuse.org/request/show/721060
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-trio?expand=0&rev=8
2019-08-05 20:07:36 +02:00
|
|
|
BuildRequires: %{python_module yapf >= 0.27.0}
|
2019-05-14 23:28:18 +02:00
|
|
|
# for protocol specifications
|
2019-05-14 22:35:45 +02:00
|
|
|
BuildRequires: %{python_module sniffio}
|
|
|
|
|
BuildRequires: %{python_module sortedcontainers}
|
2019-05-14 23:28:18 +02:00
|
|
|
BuildRequires: %{python_module trustme}
|
2019-05-14 22:35:45 +02:00
|
|
|
BuildRequires: fdupes
|
2019-05-14 23:28:18 +02:00
|
|
|
BuildRequires: netcfg
|
|
|
|
|
BuildRequires: python-rpm-macros
|
2019-05-14 22:35:45 +02:00
|
|
|
Requires: python-async_generator >= 1.9
|
2020-01-11 22:16:07 +01:00
|
|
|
Requires: python-attrs >= 19.2.0
|
2019-05-14 22:35:45 +02:00
|
|
|
Requires: python-idna
|
|
|
|
|
Requires: python-outcome
|
|
|
|
|
Requires: python-sniffio
|
|
|
|
|
Requires: python-sortedcontainers
|
|
|
|
|
BuildArch: noarch
|
2019-05-14 23:28:18 +02:00
|
|
|
%if "%{python_flavor}" < "3.7"
|
|
|
|
|
BuildRequires: %{python_module contextvars >= 2.1}
|
|
|
|
|
%endif
|
|
|
|
|
%if "%{python_flavor}" < "3.7"
|
|
|
|
|
Recommends: python-contextvars >= 2.1
|
|
|
|
|
%endif
|
2019-05-14 22:35:45 +02:00
|
|
|
%python_subpackages
|
|
|
|
|
|
|
|
|
|
%description
|
2019-06-03 10:05:03 +02:00
|
|
|
The Trio project produces an async/await-native I/O library for
|
|
|
|
|
Python. Like all async libraries, its main purpose is to help write
|
|
|
|
|
programs that do multiple things at the same time with parallelized
|
|
|
|
|
I/O, such as a web spider that wants to fetch lots of pages in
|
|
|
|
|
parallel, a web server that needs to juggle lots of downloads and
|
|
|
|
|
websocket connections at the same time, a process supervisor
|
|
|
|
|
monitoring multiple subprocesses. Compared to other libraries, Trio
|
|
|
|
|
has an obsessive focus on usability and correctness.
|
2019-05-14 22:35:45 +02:00
|
|
|
|
|
|
|
|
%prep
|
|
|
|
|
%setup -q -n trio-%{version}
|
|
|
|
|
|
|
|
|
|
%build
|
|
|
|
|
%python_build
|
|
|
|
|
|
|
|
|
|
%install
|
|
|
|
|
%python_install
|
|
|
|
|
%python_expand %fdupes %{buildroot}%{$python_sitelib}
|
|
|
|
|
|
|
|
|
|
%check
|
2019-05-14 23:28:18 +02:00
|
|
|
# test_static_tool_sees_all_symbols uses jedi/pylint for static analysis,
|
|
|
|
|
# pointless for us.
|
2019-05-22 15:02:57 +02:00
|
|
|
# test_SSLStream_generic deadlocks in OBS
|
Accepting request 721060 from home:pgajdos
- version update to 0.12.1
Features
* If you have a `~trio.abc.ReceiveStream` object, you can now use
``async for data in stream: ...`` instead of calling
`~trio.abc.ReceiveStream.receive_some`. Each iteration gives an
arbitrary sized chunk of bytes. And the best part is, the loop
automatically exits when you reach EOF, so you don't have to check for
it yourself anymore. Relatedly, you no longer need to pick a magic
buffer size value before calling
`~trio.abc.ReceiveStream.receive_some`; you can ``await
stream.receive_some()`` with no arguments, and the stream will
automatically pick a reasonable size for you. (`#959 <https://github.com/python-trio/trio/issues/959>`__)
* Threading interfaces have been reworked:
``run_sync_in_worker_thread`` is now `trio.to_thread.run_sync`, and
instead of ``BlockingTrioPortal``, use `trio.from_thread.run` and
`trio.from_thread.run_sync`. What's neat about this is that these
cooperate, so if you're in a thread created by `to_thread.run_sync`,
it remembers which Trio created it, and you can call
``trio.from_thread.*`` directly without having to pass around a
``BlockingTrioPortal`` object everywhere. (`#810 <https://github.com/python-trio/trio/issues/810>`__)
* We cleaned up the distinction between the "abstract channel interface"
and the "memory channel" concrete implementation.
`trio.abc.SendChannel` and `trio.abc.ReceiveChannel` have been slimmed
down, `trio.MemorySendChannel` and `trio.MemoryReceiveChannel` are now
public types that can be used in type hints, and there's a new
`trio.abc.Channel` interface for future bidirectional channels. (`#719 <https://github.com/python-trio/trio/issues/719>`__)
* Add :func:`trio.run_process` as a high-level helper for running a process
and waiting for it to finish, like the standard :func:`subprocess.run` does. (`#822 <https://github.com/python-trio/trio/issues/822>`__)
* On Linux, when wrapping a bare file descriptor in a Trio socket object,
Trio now auto-detects the correct ``family``, ``type``, and ``protocol``.
OBS-URL: https://build.opensuse.org/request/show/721060
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-trio?expand=0&rev=8
2019-08-05 20:07:36 +02:00
|
|
|
%pytest -k 'not (test_static_tool_sees_all_symbols or test_SSLStream_generic)'
|
2019-05-14 22:35:45 +02:00
|
|
|
|
|
|
|
|
%files %{python_files}
|
|
|
|
|
%doc README.rst
|
|
|
|
|
%license LICENSE LICENSE.APACHE2 LICENSE.MIT
|
|
|
|
|
%{python_sitelib}/*
|
|
|
|
|
|
|
|
|
|
%changelog
|
