automatic import of python3-django-pytestopeneuler20.03

3 files changed, 190 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..53af830 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/django-pytest-0.2.0.tar.gz
diff --git a/python-django-pytest.spec b/python-django-pytest.spec
new file mode 100644
index 0000000..33d90af
--- /dev/null
+++ b/python-django-pytest.spec
@@ -0,0 +1,188 @@
+%global _empty_manifest_terminate_build 0
+Name:		python-django-pytest
+Version:	0.2.0
+Release:	1
+Summary:	django test runner to use py.test tests
+License:	LICENSE.txt
+URL:		http://github.com/buchuki/django-pytest
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/b2/e2/2a87105042c08a6f116aac1d9c666e89982a4f707652a0f7d76e8a88b554/django-pytest-0.2.0.tar.gz
+BuildArch:	noarch
+
+
+%description
+This project allows you to use py.test as a django test runner, instead of the
+default test runner.
+To use it, add it to your python path and add `django_pytest` to your installed
+apps. Also set the `TEST_RUNNER = 'django_pytest.test_runner.run_tests'` setting.
+If you're using Django 1.3 or newer set
+`TEST_RUNNER = 'django_pytest.test_runner.TestRunner'` or Django will print
+deprecation warnings each time you run your tests.
+Also create a `conftest.py` in your project directory and include:
+	from django_pytest.conftest import pytest_funcarg__client, pytest_funcarg__django_client
+You can also use:
+	from django_pytest.auth_funcargs import pytest_funcarg__user, pytest_funcarg__groups
+to import a user or some groups with users in them
+Now anywhere in your project, you can create files called
+`test_<something>.py`.  These are standard py.test test files. Use the funcarg
+`client` in every test to both instantiate a test database that is cleared
+after each test and to provide you with a django test client object identical
+to the one used in django's test system. For example:
+	def test_filter(client):
+    	response = client.get('/browse/', {'filter': '1'})
+    	assert response.status_code == 200
+Use `./manage.py test` to run the py.test test runs (ie: it replaces the
+standard django test runner). You can pass py.test options to the command
+and they will be forwarded to py.test. (Technically, I haven't got it passing
+all options, just the most common ones I use)
+The management command has been set up so that syncdb will use the django core
+syncdb if `SOUTH_TESTS_MIGRATE` is set to False, if south is installed. This
+prevents migrations from running when running unit tests. This speeds up test
+setup significantly, but it means your test db may not be identical to
+production, if you have faulty migrations.
+py.test automatically picks up any subclasses of `unittest.TestCase`, provided
+they are in a module named `test_<something>.py`. Thus, all your existing django
+unittests should work seemlessly with py.test, although you may have to rename
+your test files if they do not conform to this convention. You can also write
+custom py.test test collection hooks to pick up test modules that are named in
+a different directory structure.
+This project differs from <http://github.com/bfirsh/pytest_django> in that it
+provides a django test runner that calls py.test, rather than creating a
+py.test plugin to test django projects. I believe there is overlapping
+functionality from the two projects, and also that they can be integrated into
+a single project, but I have not looked at the feasibility of this yet.
+
+%package -n python3-django-pytest
+Summary:	django test runner to use py.test tests
+Provides:	python-django-pytest
+BuildRequires:	python3-devel
+BuildRequires:	python3-setuptools
+%description -n python3-django-pytest
+This project allows you to use py.test as a django test runner, instead of the
+default test runner.
+To use it, add it to your python path and add `django_pytest` to your installed
+apps. Also set the `TEST_RUNNER = 'django_pytest.test_runner.run_tests'` setting.
+If you're using Django 1.3 or newer set
+`TEST_RUNNER = 'django_pytest.test_runner.TestRunner'` or Django will print
+deprecation warnings each time you run your tests.
+Also create a `conftest.py` in your project directory and include:
+	from django_pytest.conftest import pytest_funcarg__client, pytest_funcarg__django_client
+You can also use:
+	from django_pytest.auth_funcargs import pytest_funcarg__user, pytest_funcarg__groups
+to import a user or some groups with users in them
+Now anywhere in your project, you can create files called
+`test_<something>.py`.  These are standard py.test test files. Use the funcarg
+`client` in every test to both instantiate a test database that is cleared
+after each test and to provide you with a django test client object identical
+to the one used in django's test system. For example:
+	def test_filter(client):
+    	response = client.get('/browse/', {'filter': '1'})
+    	assert response.status_code == 200
+Use `./manage.py test` to run the py.test test runs (ie: it replaces the
+standard django test runner). You can pass py.test options to the command
+and they will be forwarded to py.test. (Technically, I haven't got it passing
+all options, just the most common ones I use)
+The management command has been set up so that syncdb will use the django core
+syncdb if `SOUTH_TESTS_MIGRATE` is set to False, if south is installed. This
+prevents migrations from running when running unit tests. This speeds up test
+setup significantly, but it means your test db may not be identical to
+production, if you have faulty migrations.
+py.test automatically picks up any subclasses of `unittest.TestCase`, provided
+they are in a module named `test_<something>.py`. Thus, all your existing django
+unittests should work seemlessly with py.test, although you may have to rename
+your test files if they do not conform to this convention. You can also write
+custom py.test test collection hooks to pick up test modules that are named in
+a different directory structure.
+This project differs from <http://github.com/bfirsh/pytest_django> in that it
+provides a django test runner that calls py.test, rather than creating a
+py.test plugin to test django projects. I believe there is overlapping
+functionality from the two projects, and also that they can be integrated into
+a single project, but I have not looked at the feasibility of this yet.
+
+%package help
+Summary:	Development documents and examples for django-pytest
+Provides:	python3-django-pytest-doc
+%description help
+This project allows you to use py.test as a django test runner, instead of the
+default test runner.
+To use it, add it to your python path and add `django_pytest` to your installed
+apps. Also set the `TEST_RUNNER = 'django_pytest.test_runner.run_tests'` setting.
+If you're using Django 1.3 or newer set
+`TEST_RUNNER = 'django_pytest.test_runner.TestRunner'` or Django will print
+deprecation warnings each time you run your tests.
+Also create a `conftest.py` in your project directory and include:
+	from django_pytest.conftest import pytest_funcarg__client, pytest_funcarg__django_client
+You can also use:
+	from django_pytest.auth_funcargs import pytest_funcarg__user, pytest_funcarg__groups
+to import a user or some groups with users in them
+Now anywhere in your project, you can create files called
+`test_<something>.py`.  These are standard py.test test files. Use the funcarg
+`client` in every test to both instantiate a test database that is cleared
+after each test and to provide you with a django test client object identical
+to the one used in django's test system. For example:
+	def test_filter(client):
+    	response = client.get('/browse/', {'filter': '1'})
+    	assert response.status_code == 200
+Use `./manage.py test` to run the py.test test runs (ie: it replaces the
+standard django test runner). You can pass py.test options to the command
+and they will be forwarded to py.test. (Technically, I haven't got it passing
+all options, just the most common ones I use)
+The management command has been set up so that syncdb will use the django core
+syncdb if `SOUTH_TESTS_MIGRATE` is set to False, if south is installed. This
+prevents migrations from running when running unit tests. This speeds up test
+setup significantly, but it means your test db may not be identical to
+production, if you have faulty migrations.
+py.test automatically picks up any subclasses of `unittest.TestCase`, provided
+they are in a module named `test_<something>.py`. Thus, all your existing django
+unittests should work seemlessly with py.test, although you may have to rename
+your test files if they do not conform to this convention. You can also write
+custom py.test test collection hooks to pick up test modules that are named in
+a different directory structure.
+This project differs from <http://github.com/bfirsh/pytest_django> in that it
+provides a django test runner that calls py.test, rather than creating a
+py.test plugin to test django projects. I believe there is overlapping
+functionality from the two projects, and also that they can be integrated into
+a single project, but I have not looked at the feasibility of this yet.
+
+%prep
+%autosetup -n django-pytest-0.2.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-django-pytest -f filelist.lst
+%dir %{python3_sitelib}/*
+
+%files help -f doclist.lst
+%{_docdir}/*
+
+%changelog
+* Fri Feb 24 2023 Python_Bot <Python_Bot@openeuler.org> - 0.2.0-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..5edacea
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+f44f8792994501c37efaf7d44b7baf4e  django-pytest-0.2.0.tar.gz