SHA256
1
0
forked from pool/python-trio
python-trio/python-trio.spec
Tomáš Chvátal 7d48798b7b 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 18:07:36 +00:00

92 lines
3.2 KiB
RPMSpec

#
# spec file for package python-trio
#
# Copyright (c) 2019 SUSE LINUX GmbH, Nuernberg, Germany.
#
# 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.
# Please submit bugfixes or comments via https://bugs.opensuse.org/
#
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
%define skip_python2 1
Name: python-trio
Version: 0.12.1
Release: 0
Summary: An async/await-native I/O library
License: MIT OR Apache-2.0
Group: Development/Languages/Python
URL: https://github.com/python-trio/trio
Source: https://github.com/python-trio/trio/archive/v%{version}.tar.gz#/trio-%{version}.tar.gz
BuildRequires: %{python_module astor >= 0.8}
BuildRequires: %{python_module async_generator >= 1.9}
BuildRequires: %{python_module attrs >= 18.2.0}
BuildRequires: %{python_module idna}
BuildRequires: %{python_module outcome}
BuildRequires: %{python_module pyOpenSSL}
BuildRequires: %{python_module pytest}
BuildRequires: %{python_module setuptools}
BuildRequires: %{python_module yapf >= 0.27.0}
# for protocol specifications
BuildRequires: %{python_module sniffio}
BuildRequires: %{python_module sortedcontainers}
BuildRequires: %{python_module trustme}
BuildRequires: fdupes
BuildRequires: netcfg
BuildRequires: python-rpm-macros
Requires: python-async_generator >= 1.9
Requires: python-attrs >= 18.2.0
Requires: python-idna
Requires: python-outcome
Requires: python-sniffio
Requires: python-sortedcontainers
BuildArch: noarch
%if "%{python_flavor}" < "3.7"
BuildRequires: %{python_module contextvars >= 2.1}
%endif
%if "%{python_flavor}" < "3.7"
Recommends: python-contextvars >= 2.1
%endif
%python_subpackages
%description
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.
%prep
%setup -q -n trio-%{version}
%build
%python_build
%install
%python_install
%python_expand %fdupes %{buildroot}%{$python_sitelib}
%check
# test_static_tool_sees_all_symbols uses jedi/pylint for static analysis,
# pointless for us.
# test_SSLStream_generic deadlocks in OBS
%pytest -k 'not (test_static_tool_sees_all_symbols or test_SSLStream_generic)'
%files %{python_files}
%doc README.rst
%license LICENSE LICENSE.APACHE2 LICENSE.MIT
%{python_sitelib}/*
%changelog