automatic import of python-nine

3 files changed, 152 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..f05aaf3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/nine-1.1.0.tar.gz
diff --git a/python-nine.spec b/python-nine.spec
new file mode 100644
index 0000000..b0103bc
--- /dev/null
+++ b/python-nine.spec
@@ -0,0 +1,150 @@
+%global _empty_manifest_terminate_build 0
+Name:		python-nine
+Version:	1.1.0
+Release:	1
+Summary:	Python 2 / 3 compatibility, like six, but favouring Python 3
+License:	Public domain
+URL:		https://github.com/nandoflorestan/nine
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/ba/1f/0c7e2a1e28497df5d207199b5e70aa998e501659eeb84076a6cf78809540/nine-1.1.0.tar.gz
+BuildArch:	noarch
+
+
+%description
+When the best Python 2/Python 3 compatibility modules -- especially the famous
+`*six* library invented by Benjamin Peterson <https://pypi.python.org/pypi/six>`_
+-- were created, they were written from the point of view of a Python 2
+programmer starting to grok Python 3.  If you use *six*,
+your code is compatible, but stuck in Python 2 idioms.
+**nine** turns **six** upside down. You write your code using Python 3 idioms
+-- as much as possible --, and it is the Python 2 "version" that is patched.
+Needless to say, this approach is more future-proof.
+When thou writeth Python, thou shalt write Python 3 and,
+just for a little longer, ensure that the thing worketh on Python 2.7.
+*nine* facilitates this point of view. You can write code
+that is as 3ish as possible while still supporting 2.6.
+For instance, you don't type ``unicode`` anymore, you type ``str``, and *nine*
+makes ``str`` point to ``unicode`` on Python 2 (if you use our boilerplate).
+Also, ``map``, ``zip`` and ``filter`` have Python 3 behaviour, on Python 2,
+meaning they return iterators, not lists.
+Honestly you should not spend one thought on Python 2.6 anymore, it is
+`no longer supported <https://mail.python.org/pipermail/python-dev/2013-September/128287.html>`_
+since its final release (2.6.9) in October 2013. Nobody uses 3.0 or 3.1 either.
+Python 2.7 has finally met its demise on the first day of 2020.
+*nine* is extremely stable and unlikely to change since it solves an old
+problem that never changes.  Nobody should be surprised if *nine* isn't
+updated for months or even years.
+The author(s) of *nine* donate this module to the public domain.
+To understand most of the intricacies involved in achieving 2&3 compatibility
+in a single codebase, I recommend reading this:
+http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
+
+%package -n python3-nine
+Summary:	Python 2 / 3 compatibility, like six, but favouring Python 3
+Provides:	python-nine
+BuildRequires:	python3-devel
+BuildRequires:	python3-setuptools
+BuildRequires:	python3-pip
+%description -n python3-nine
+When the best Python 2/Python 3 compatibility modules -- especially the famous
+`*six* library invented by Benjamin Peterson <https://pypi.python.org/pypi/six>`_
+-- were created, they were written from the point of view of a Python 2
+programmer starting to grok Python 3.  If you use *six*,
+your code is compatible, but stuck in Python 2 idioms.
+**nine** turns **six** upside down. You write your code using Python 3 idioms
+-- as much as possible --, and it is the Python 2 "version" that is patched.
+Needless to say, this approach is more future-proof.
+When thou writeth Python, thou shalt write Python 3 and,
+just for a little longer, ensure that the thing worketh on Python 2.7.
+*nine* facilitates this point of view. You can write code
+that is as 3ish as possible while still supporting 2.6.
+For instance, you don't type ``unicode`` anymore, you type ``str``, and *nine*
+makes ``str`` point to ``unicode`` on Python 2 (if you use our boilerplate).
+Also, ``map``, ``zip`` and ``filter`` have Python 3 behaviour, on Python 2,
+meaning they return iterators, not lists.
+Honestly you should not spend one thought on Python 2.6 anymore, it is
+`no longer supported <https://mail.python.org/pipermail/python-dev/2013-September/128287.html>`_
+since its final release (2.6.9) in October 2013. Nobody uses 3.0 or 3.1 either.
+Python 2.7 has finally met its demise on the first day of 2020.
+*nine* is extremely stable and unlikely to change since it solves an old
+problem that never changes.  Nobody should be surprised if *nine* isn't
+updated for months or even years.
+The author(s) of *nine* donate this module to the public domain.
+To understand most of the intricacies involved in achieving 2&3 compatibility
+in a single codebase, I recommend reading this:
+http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
+
+%package help
+Summary:	Development documents and examples for nine
+Provides:	python3-nine-doc
+%description help
+When the best Python 2/Python 3 compatibility modules -- especially the famous
+`*six* library invented by Benjamin Peterson <https://pypi.python.org/pypi/six>`_
+-- were created, they were written from the point of view of a Python 2
+programmer starting to grok Python 3.  If you use *six*,
+your code is compatible, but stuck in Python 2 idioms.
+**nine** turns **six** upside down. You write your code using Python 3 idioms
+-- as much as possible --, and it is the Python 2 "version" that is patched.
+Needless to say, this approach is more future-proof.
+When thou writeth Python, thou shalt write Python 3 and,
+just for a little longer, ensure that the thing worketh on Python 2.7.
+*nine* facilitates this point of view. You can write code
+that is as 3ish as possible while still supporting 2.6.
+For instance, you don't type ``unicode`` anymore, you type ``str``, and *nine*
+makes ``str`` point to ``unicode`` on Python 2 (if you use our boilerplate).
+Also, ``map``, ``zip`` and ``filter`` have Python 3 behaviour, on Python 2,
+meaning they return iterators, not lists.
+Honestly you should not spend one thought on Python 2.6 anymore, it is
+`no longer supported <https://mail.python.org/pipermail/python-dev/2013-September/128287.html>`_
+since its final release (2.6.9) in October 2013. Nobody uses 3.0 or 3.1 either.
+Python 2.7 has finally met its demise on the first day of 2020.
+*nine* is extremely stable and unlikely to change since it solves an old
+problem that never changes.  Nobody should be surprised if *nine* isn't
+updated for months or even years.
+The author(s) of *nine* donate this module to the public domain.
+To understand most of the intricacies involved in achieving 2&3 compatibility
+in a single codebase, I recommend reading this:
+http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
+
+%prep
+%autosetup -n nine-1.1.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-nine -f filelist.lst
+%dir %{python3_sitelib}/*
+
+%files help -f doclist.lst
+%{_docdir}/*
+
+%changelog
+* Thu Mar 09 2023 Python_Bot <Python_Bot@openeuler.org> - 1.1.0-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..047bcbe
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+b7430863fbd8569cd43e323b01657a94  nine-1.1.0.tar.gz