automatic import of python-django-unmigrateopeneuler20.03

3 files changed, 118 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..620b869 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/django-unmigrate-0.3.1.tar.gz
diff --git a/python-django-unmigrate.spec b/python-django-unmigrate.spec
new file mode 100644
index 0000000..1bd12b4
--- /dev/null
+++ b/python-django-unmigrate.spec
@@ -0,0 +1,116 @@
+%global _empty_manifest_terminate_build 0
+Name:		python-django-unmigrate
+Version:	0.3.1
+Release:	1
+Summary:	Smart reversion of Django migrations based on Git diff
+License:	MIT
+URL:		https://github.com/lorinkoz/django-unmigrate
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/92/f7/b00c7611ca4747aeb639a3c635f495c7c7262ddc7e5ec823e6679ea2e3ca/django-unmigrate-0.3.1.tar.gz
+BuildArch:	noarch
+
+Requires:	python3-GitPython
+Requires:	python3-django
+
+%description
+|
+If you are in a complex Django project, sometimes you will find yourself switching
+between multiple branches, some of which can add a number of database migrations.
+Before switching back to ``master`` you will have to unapply all migrations that
+are specific to the current branch. In order to unapply these, you will have to
+enter the migration that comes right before the first migration of the current
+branch. If two or more apps are involved, you will have to do that for each one
+of them.
+If you leave your migration names unchanged, inferring the name of the right
+migration to target is not too difficult, because they are prefixed by default
+with a sequential number. Django also helps, being smart enough to let you use
+an unambiguous prefix of any migration name. Add a merge migration and the
+numbers will no longer be so obvious. Or if you have renamed your migration
+files to drop the sequential numbers you will have to do the search manually.
+With ``django-unmigrate`` you can speed up the process.
+
+%package -n python3-django-unmigrate
+Summary:	Smart reversion of Django migrations based on Git diff
+Provides:	python-django-unmigrate
+BuildRequires:	python3-devel
+BuildRequires:	python3-setuptools
+BuildRequires:	python3-pip
+%description -n python3-django-unmigrate
+|
+If you are in a complex Django project, sometimes you will find yourself switching
+between multiple branches, some of which can add a number of database migrations.
+Before switching back to ``master`` you will have to unapply all migrations that
+are specific to the current branch. In order to unapply these, you will have to
+enter the migration that comes right before the first migration of the current
+branch. If two or more apps are involved, you will have to do that for each one
+of them.
+If you leave your migration names unchanged, inferring the name of the right
+migration to target is not too difficult, because they are prefixed by default
+with a sequential number. Django also helps, being smart enough to let you use
+an unambiguous prefix of any migration name. Add a merge migration and the
+numbers will no longer be so obvious. Or if you have renamed your migration
+files to drop the sequential numbers you will have to do the search manually.
+With ``django-unmigrate`` you can speed up the process.
+
+%package help
+Summary:	Development documents and examples for django-unmigrate
+Provides:	python3-django-unmigrate-doc
+%description help
+|
+If you are in a complex Django project, sometimes you will find yourself switching
+between multiple branches, some of which can add a number of database migrations.
+Before switching back to ``master`` you will have to unapply all migrations that
+are specific to the current branch. In order to unapply these, you will have to
+enter the migration that comes right before the first migration of the current
+branch. If two or more apps are involved, you will have to do that for each one
+of them.
+If you leave your migration names unchanged, inferring the name of the right
+migration to target is not too difficult, because they are prefixed by default
+with a sequential number. Django also helps, being smart enough to let you use
+an unambiguous prefix of any migration name. Add a merge migration and the
+numbers will no longer be so obvious. Or if you have renamed your migration
+files to drop the sequential numbers you will have to do the search manually.
+With ``django-unmigrate`` you can speed up the process.
+
+%prep
+%autosetup -n django-unmigrate-0.3.1
+
+%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-django-unmigrate -f filelist.lst
+%dir %{python3_sitelib}/*
+
+%files help -f doclist.lst
+%{_docdir}/*
+
+%changelog
+* Wed Apr 12 2023 Python_Bot <Python_Bot@openeuler.org> - 0.3.1-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..9b25a45
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+df3e77b1676f508c16b693e731af6ed7  django-unmigrate-0.3.1.tar.gz