%global _empty_manifest_terminate_build 0
Name:		python-show
Version:	1.6.0
Release:	1
Summary:	Debug print statements, done right. E.g. show(x)
License:	Apache License 2.0
URL:		https://bitbucket.org/jeunice/show
Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/2d/b3/b2edb821a57a0dbefd65fb5e5971d7b876c0b835b5c72516262e91a65ec2/show-1.6.0.zip
BuildArch:	noarch


%description
Logging, assertions, unit tests, and interactive debuggers are all great
tools. But sometimes you just need to print values as a program runs to see
what's going on. Every language has features to print text, but they're
rarely customized for printing debugging information. ``show`` is. It
provides a simple, DRY mechanism to "show what's going on."
Sometimes programs print so that users can see things, and sometimes they
print so that developers can. ``show()`` is for developers, helping rapidly
print the current state of variables in ways that easily identify what
value is being printed, without a lot of wasted effort. It replaces the
craptastic repetitiveness of::
    print "x: {0!r}".format(x)
with::
    show(x)
And if you have a lot of output flowing by, and it's hard
to see your debugging output, try::
    show(x, y, z, style='red')
And now you have debug output that clearly stands out from the rest.
But "debug printing is so very 1989!" you may say.  "We now have logging,
logging, embedded assertions, unit tests, ..." Yes, that's true. But wonderful
as those things are, just showing your current program values is often
what the doctor ordered.

%package -n python3-show
Summary:	Debug print statements, done right. E.g. show(x)
Provides:	python-show
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
%description -n python3-show
Logging, assertions, unit tests, and interactive debuggers are all great
tools. But sometimes you just need to print values as a program runs to see
what's going on. Every language has features to print text, but they're
rarely customized for printing debugging information. ``show`` is. It
provides a simple, DRY mechanism to "show what's going on."
Sometimes programs print so that users can see things, and sometimes they
print so that developers can. ``show()`` is for developers, helping rapidly
print the current state of variables in ways that easily identify what
value is being printed, without a lot of wasted effort. It replaces the
craptastic repetitiveness of::
    print "x: {0!r}".format(x)
with::
    show(x)
And if you have a lot of output flowing by, and it's hard
to see your debugging output, try::
    show(x, y, z, style='red')
And now you have debug output that clearly stands out from the rest.
But "debug printing is so very 1989!" you may say.  "We now have logging,
logging, embedded assertions, unit tests, ..." Yes, that's true. But wonderful
as those things are, just showing your current program values is often
what the doctor ordered.

%package help
Summary:	Development documents and examples for show
Provides:	python3-show-doc
%description help
Logging, assertions, unit tests, and interactive debuggers are all great
tools. But sometimes you just need to print values as a program runs to see
what's going on. Every language has features to print text, but they're
rarely customized for printing debugging information. ``show`` is. It
provides a simple, DRY mechanism to "show what's going on."
Sometimes programs print so that users can see things, and sometimes they
print so that developers can. ``show()`` is for developers, helping rapidly
print the current state of variables in ways that easily identify what
value is being printed, without a lot of wasted effort. It replaces the
craptastic repetitiveness of::
    print "x: {0!r}".format(x)
with::
    show(x)
And if you have a lot of output flowing by, and it's hard
to see your debugging output, try::
    show(x, y, z, style='red')
And now you have debug output that clearly stands out from the rest.
But "debug printing is so very 1989!" you may say.  "We now have logging,
logging, embedded assertions, unit tests, ..." Yes, that's true. But wonderful
as those things are, just showing your current program values is often
what the doctor ordered.

%prep
%autosetup -n show-1.6.0

%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-show -f filelist.lst
%dir %{python3_sitelib}/*

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

%changelog
* Mon May 15 2023 Python_Bot <Python_Bot@openeuler.org> - 1.6.0-1
- Package Spec generated