%global _empty_manifest_terminate_build 0
Name:		python-precisely
Version:	0.1.9
Release:	1
Summary:	Rich matchers, useful for assertions in tests. Inspired by Hamcrest.
License:	BSD-2-Clause
URL:		http://github.com/mwilliamson/python-precisely
Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/e0/f6/eb04e28fc004457cc3acd10eaac21d05b3fa11d8d36b7c63b73d0d017311/precisely-0.1.9.tar.gz
BuildArch:	noarch


%description
Precisely allows you to write precise assertions so you only test the behaviour you're really interested in.
This makes it clearer to the reader what the expected behaviour is,
and makes tests less brittle.
This also allows better error messages to be generated when assertions fail.
Inspired by Hamcrest_.
For instance, suppose we want to make sure that a ``unique`` function removes duplicates from a list.
We might write a test like so:
    from precisely import assert_that, contains_exactly
    def test_unique_removes_duplicates():
        result = unique(["a", "a", "b", "a", "b"])
        assert_that(result, contains_exactly("a", "b"))
The assertion will pass so long as ``result`` contains ``"a"`` and ``"b"`` in any order,
but no other items.
Unlike, say, ``assert result == ["a", "b"]``, our assertion ignores the ordering of elements.
This is useful when:
* the ordering of the result is non-determistic, such as when using ``set``.
* the ordering isn't specified in the contract of ``unique``.
  If we assert a particular ordering, then we'd be testing the implementation rather than the contract.
* the ordering is specified in the contract of ``unique``,
  but the ordering is tested in a separate test case.
When the assertion fails,
rather than just stating the two values weren't equal,
the error message will describe the failure in more detail.
For instance, if unique has the value ``["a", "a", "b"]``,
we'd get the failure message::
    Expected: iterable containing in any order:
      * 'a'
      * 'b'
    but: had extra elements:
      * 'a'

%package -n python3-precisely
Summary:	Rich matchers, useful for assertions in tests. Inspired by Hamcrest.
Provides:	python-precisely
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
%description -n python3-precisely
Precisely allows you to write precise assertions so you only test the behaviour you're really interested in.
This makes it clearer to the reader what the expected behaviour is,
and makes tests less brittle.
This also allows better error messages to be generated when assertions fail.
Inspired by Hamcrest_.
For instance, suppose we want to make sure that a ``unique`` function removes duplicates from a list.
We might write a test like so:
    from precisely import assert_that, contains_exactly
    def test_unique_removes_duplicates():
        result = unique(["a", "a", "b", "a", "b"])
        assert_that(result, contains_exactly("a", "b"))
The assertion will pass so long as ``result`` contains ``"a"`` and ``"b"`` in any order,
but no other items.
Unlike, say, ``assert result == ["a", "b"]``, our assertion ignores the ordering of elements.
This is useful when:
* the ordering of the result is non-determistic, such as when using ``set``.
* the ordering isn't specified in the contract of ``unique``.
  If we assert a particular ordering, then we'd be testing the implementation rather than the contract.
* the ordering is specified in the contract of ``unique``,
  but the ordering is tested in a separate test case.
When the assertion fails,
rather than just stating the two values weren't equal,
the error message will describe the failure in more detail.
For instance, if unique has the value ``["a", "a", "b"]``,
we'd get the failure message::
    Expected: iterable containing in any order:
      * 'a'
      * 'b'
    but: had extra elements:
      * 'a'

%package help
Summary:	Development documents and examples for precisely
Provides:	python3-precisely-doc
%description help
Precisely allows you to write precise assertions so you only test the behaviour you're really interested in.
This makes it clearer to the reader what the expected behaviour is,
and makes tests less brittle.
This also allows better error messages to be generated when assertions fail.
Inspired by Hamcrest_.
For instance, suppose we want to make sure that a ``unique`` function removes duplicates from a list.
We might write a test like so:
    from precisely import assert_that, contains_exactly
    def test_unique_removes_duplicates():
        result = unique(["a", "a", "b", "a", "b"])
        assert_that(result, contains_exactly("a", "b"))
The assertion will pass so long as ``result`` contains ``"a"`` and ``"b"`` in any order,
but no other items.
Unlike, say, ``assert result == ["a", "b"]``, our assertion ignores the ordering of elements.
This is useful when:
* the ordering of the result is non-determistic, such as when using ``set``.
* the ordering isn't specified in the contract of ``unique``.
  If we assert a particular ordering, then we'd be testing the implementation rather than the contract.
* the ordering is specified in the contract of ``unique``,
  but the ordering is tested in a separate test case.
When the assertion fails,
rather than just stating the two values weren't equal,
the error message will describe the failure in more detail.
For instance, if unique has the value ``["a", "a", "b"]``,
we'd get the failure message::
    Expected: iterable containing in any order:
      * 'a'
      * 'b'
    but: had extra elements:
      * 'a'

%prep
%autosetup -n precisely-0.1.9

%build
%py3_build

%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
	find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
	find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
	find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
	find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
	find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .

%files -n python3-precisely -f filelist.lst
%dir %{python3_sitelib}/*

%files help -f doclist.lst
%{_docdir}/*

%changelog
* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 0.1.9-1
- Package Spec generated