automatic import of python-show

3 files changed, 134 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..235f565 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/show-1.6.0.zip
diff --git a/python-show.spec b/python-show.spec
new file mode 100644
index 0000000..451abc8
--- /dev/null
+++ b/python-show.spec
@@ -0,0 +1,132 @@
+%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
diff --git a/sources b/sources
new file mode 100644
index 0000000..75cc475
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+9236ad5c0590c627d613c302f7c4fb61  show-1.6.0.zip