diff --git a/0.14.1.tar.gz b/0.14.1.tar.gz deleted file mode 100644 index 8f59ca63a1b63f08e223d57fd8c21cb09f4df602..0000000000000000000000000000000000000000 Binary files a/0.14.1.tar.gz and /dev/null differ diff --git a/1.0.1.tar.gz b/1.0.1.tar.gz new file mode 100644 index 0000000000000000000000000000000000000000..fcf65c699988ba778a147d4f1d47a4977dded72e Binary files /dev/null and b/1.0.1.tar.gz differ diff --git a/Skip-tests-that-use-xprocess-fixture-when-not-installed.patch b/Skip-tests-that-use-xprocess-fixture-when-not-installed.patch deleted file mode 100644 index 2b0cead112caad9545b9897a458098f50f2b1234..0000000000000000000000000000000000000000 --- a/Skip-tests-that-use-xprocess-fixture-when-not-installed.patch +++ /dev/null @@ -1,133 +0,0 @@ -From 7a4e8b834ee81aeeaa5dd0458b3986d33bb69de8 Mon Sep 17 00:00:00 2001 -From: Adam Williamson -Date: Wed, 9 May 2018 15:50:50 -0700 -Subject: [PATCH] Skip tests that use 'xprocess' fixture when not installed - -There's a trick in conftest.py intended to allow tests to use -a fixture named 'subprocess', which will be the 'xprocess' -fixture if that's available, or will cause the test to be -skipped it it's not available. Some tests, however, just use -the 'xprocess' fixture directly, so all those tests fail if -it is not available. - -We don't really need this 'subprocess' fixture at all, it -turns out - we can just do the same trick directly on the -'xprocess' fixture, so all tests can use that directly (and -also there's no confusion between this wrapper fixture and the -commonly-used Python module called...subprocess). This -simplifies things and makes the whole test suite run OK when -xprocess isn't available. - -I noticed this when trying to run the test suite during build -of the Fedora package - xprocess isn't packaged for Fedora yet, -so there's no way to run the tests that use it unfortunately. - -Signed-off-by: Adam Williamson ---- - tests/conftest.py | 12 ++++-------- - tests/contrib/cache/test_cache.py | 12 ++++++------ - 2 files changed, 10 insertions(+), 14 deletions(-) - -diff --git a/tests/conftest.py b/tests/conftest.py -index ce885777a..cd78d8ceb 100644 ---- a/tests/conftest.py -+++ b/tests/conftest.py -@@ -27,12 +27,8 @@ - __import__('pytest_xprocess') - except ImportError: - @pytest.fixture(scope='session') -- def subprocess(): -+ def xprocess(): - pytest.skip('pytest-xprocess not installed.') --else: -- @pytest.fixture(scope='session') -- def subprocess(xprocess): -- return xprocess - - - port_generator = count(13220) -@@ -117,7 +113,7 @@ def wait_for_reloader_loop(self): - - - @pytest.fixture --def dev_server(tmpdir, subprocess, request, monkeypatch): -+def dev_server(tmpdir, xprocess, request, monkeypatch): - '''Run werkzeug.serving.run_simple in its own process. - - :param application: String for the module that will be created. The module -@@ -144,7 +140,7 @@ def run_dev_server(application): - url_base = 'http://localhost:{0}'.format(port) - - info = _ServerInfo( -- subprocess, -+ xprocess, - 'localhost:{0}'.format(port), - url_base, - port -@@ -154,7 +150,7 @@ def preparefunc(cwd): - args = [sys.executable, __file__, str(tmpdir)] - return lambda: 'pid=%s' % info.request_pid(), args - -- subprocess.ensure('dev_server', preparefunc, restart=True) -+ xprocess.ensure('dev_server', preparefunc, restart=True) - - def teardown(): - # Killing the process group that runs the server, not just the -diff --git a/tests/contrib/cache/test_cache.py b/tests/contrib/cache/test_cache.py -index 3e6ee7f36..0a2dac14a 100644 ---- a/tests/contrib/cache/test_cache.py -+++ b/tests/contrib/cache/test_cache.py -@@ -221,7 +221,7 @@ class TestRedisCache(GenericCacheTests): - _guaranteed_deletes = True - - @pytest.fixture(scope='class', autouse=True) -- def requirements(self, subprocess): -+ def requirements(self, xprocess): - if redis is None: - pytest.skip('Python package "redis" is not installed.') - -@@ -229,7 +229,7 @@ def prepare(cwd): - return '[Rr]eady to accept connections', ['redis-server'] - - try: -- subprocess.ensure('redis_server', prepare) -+ xprocess.ensure('redis_server', prepare) - except IOError as e: - # xprocess raises FileNotFoundError - if e.errno == errno.ENOENT: -@@ -238,7 +238,7 @@ def prepare(cwd): - raise - - yield -- subprocess.getinfo('redis_server').terminate() -+ xprocess.getinfo('redis_server').terminate() - - @pytest.fixture(params=(None, False, True)) - def make_cache(self, request): -@@ -272,7 +272,7 @@ class TestMemcachedCache(GenericCacheTests): - _can_use_fast_sleep = False - - @pytest.fixture(scope='class', autouse=True) -- def requirements(self, subprocess): -+ def requirements(self, xprocess): - if memcache is None: - pytest.skip( - 'Python package for memcache is not installed. Need one of ' -@@ -283,7 +283,7 @@ def prepare(cwd): - return '', ['memcached'] - - try: -- subprocess.ensure('memcached', prepare) -+ xprocess.ensure('memcached', prepare) - except IOError as e: - # xprocess raises FileNotFoundError - if e.errno == errno.ENOENT: -@@ -292,7 +292,7 @@ def prepare(cwd): - raise - - yield -- subprocess.getinfo('memcached').terminate() -+ xprocess.getinfo('memcached').terminate() - - @pytest.fixture - def make_cache(self): diff --git a/Werkzeug-0.14.1.tar.gz b/Werkzeug-0.14.1.tar.gz deleted file mode 100644 index 27e7b2d79bcd0c38605da95f07e3c6124df5e55d..0000000000000000000000000000000000000000 Binary files a/Werkzeug-0.14.1.tar.gz and /dev/null differ diff --git a/python-werkzeug.spec b/python-werkzeug.spec index 456650451fff1bb734fd320339ee8d7d7261f3d0..eef5b53b00d073df2d6b0590bfd9e176cb4a7038 100644 --- a/python-werkzeug.spec +++ b/python-werkzeug.spec @@ -1,44 +1,51 @@ -%global debug_package %{nil} -%global srcname Werkzeug - -Name: python-werkzeug -Summary: A comprehensive WSGI web application library -Version: 0.14.1 -Release: 6 -License: BSD -URL: http://werkzeug.pocoo.org/ -Source0: https://files.pythonhosted.org/packages/source/W/Werkzeug/%{srcname}-%{version}.tar.gz -Source1: https://github.com/pallets/werkzeug/archive/0.14.1.tar.gz - -# https://github.com/pallets/werkzeug/pull/1293 -# skip tests that use a fixture called 'subprocess' when pytest-xprocess -# is not installed -Patch0: Skip-tests-that-use-xprocess-fixture-when-not-installed.patch - -%global _description\ -Werkzeug is a comprehensive WSGI web application library. It began as a\ -simple collection of various utilities for WSGI applications and has\ -become one of the most advanced WSGI utility libraries.\ -It includes:\ -* An interactive debugger that allows inspecting stack traces and source\ -code in the browser with an interactive interpreter for any frame in the stack.\ -* A full-featured request object with objects to interact with headers,\ -query args, form data, files, and cookies.\ -* A response object that can wrap other WSGI applications and handle\ -streaming data.\ -* A routing system for matching URLs to endpoints and generating URLs for\ -endpoints, with an extensible system for capturing variables from URLs.\ -* HTTP utilities to handle entity tags, cache control, dates, user agents,\ -cookies, files, and more.\ -* A threaded WSGI server for use while developing applications locally.\ -* A test client for simulating HTTP requests during testing without\ -requiring running a server.\ -Werkzeug is Unicode aware and doesn't enforce any dependencies. It is up\ -to the developer to choose a template engine, database adapter, and even\ -how to handle requests. It can be used to build all sorts of end user\ -applications such as blogs, wikis, or bulletin boards.\ - -%description %_description +%global _empty_manifest_terminate_build 0 +Name: python-werkzeug +Version: 1.0.1 +Release: 1 +Summary: The comprehensive WSGI web application library. +License: BSD-3-Clause +URL: https://palletsprojects.com/p/werkzeug/ +Source0: https://github.com/pallets/werkzeug/archive/1.0.1.tar.gz +BuildArch: noarch + +Requires: python3-pytest +Requires: python3-pytest-timeout +Requires: python3-coverage +Requires: python3-tox +Requires: python3-sphinx +Requires: python3-pallets-sphinx-themes +Requires: python3-sphinx-issues +Requires: python3-watchdog + +%description +*werkzeug* German noun: "tool". Etymology: *werk* ("work"), *zeug* ("stuff") +Werkzeug is a comprehensive `WSGI`_ web application library. It began as +a simple collection of various utilities for WSGI applications and has +become one of the most advanced WSGI utility libraries. +It includes: +- An interactive debugger that allows inspecting stack traces and + source code in the browser with an interactive interpreter for any + frame in the stack. +- A full-featured request object with objects to interact with + headers, query args, form data, files, and cookies. +- A response object that can wrap other WSGI applications and handle + streaming data. +- A routing system for matching URLs to endpoints and generating URLs + for endpoints, with an extensible system for capturing variables + from URLs. +- HTTP utilities to handle entity tags, cache control, dates, user + agents, cookies, files, and more. +- A threaded WSGI server for use while developing applications + locally. +- A test client for simulating HTTP requests during testing without + requiring running a server. +Werkzeug is Unicode aware and doesn't enforce any dependencies. It is up +to the developer to choose a template engine, database adapter, and even +how to handle requests. It can be used to build all sorts of end user +applications such as blogs, wikis, or bulletin boards. +`Flask`_ wraps Werkzeug, using it to handle the details of WSGI while +providing more structure and patterns for defining powerful +applications. %package -n python2-werkzeug Summary: %summary @@ -63,98 +70,121 @@ Documentation and examples for %{name}. %package -n python3-werkzeug -Summary: %summary - -BuildRequires: python3-devel python3-setuptools git -# For tests -BuildRequires: python3-pytest python3-hypothesis python3-requests python3-pyOpenSSL -BuildRequires: python3-greenlet python3-redis - -%{?python_provide:%python_provide python3-werkzeug} - -%description -n python3-werkzeug %_description - - -%package -n python3-werkzeug-doc -Summary: Documentation for python3-werkzeug -BuildRequires: python3-sphinx -Requires: python3-werkzeug = %{version}-%{release} -%{?python_provide:%python_provide python3-werkzeug-doc} - -%description -n python3-werkzeug-doc -Documentation and examples for python3-werkzeug. - +Summary: The comprehensive WSGI web application library. +Provides: python-werkzeug +BuildRequires: python3-devel +BuildRequires: python3-pytest +BuildRequires: python3-pytest-timeout +BuildRequires: python3-requests +BuildRequires: python3-setuptools +BuildRequires: python3-cryptography +BuildRequires: python3-greenlet +%description -n python3-werkzeug +*werkzeug* German noun: "tool". Etymology: *werk* ("work"), *zeug* ("stuff") +Werkzeug is a comprehensive `WSGI`_ web application library. It began as +a simple collection of various utilities for WSGI applications and has +become one of the most advanced WSGI utility libraries. +It includes: +- An interactive debugger that allows inspecting stack traces and + source code in the browser with an interactive interpreter for any + frame in the stack. +- A full-featured request object with objects to interact with + headers, query args, form data, files, and cookies. +- A response object that can wrap other WSGI applications and handle + streaming data. +- A routing system for matching URLs to endpoints and generating URLs + for endpoints, with an extensible system for capturing variables + from URLs. +- HTTP utilities to handle entity tags, cache control, dates, user + agents, cookies, files, and more. +- A threaded WSGI server for use while developing applications + locally. +- A test client for simulating HTTP requests during testing without + requiring running a server. +Werkzeug is Unicode aware and doesn't enforce any dependencies. It is up +to the developer to choose a template engine, database adapter, and even +how to handle requests. It can be used to build all sorts of end user +applications such as blogs, wikis, or bulletin boards. +`Flask`_ wraps Werkzeug, using it to handle the details of WSGI while +providing more structure and patterns for defining powerful +applications. + +%package help +Summary: Development documents and examples for Werkzeug +Provides: python3-werkzeug-doc +%description help +*werkzeug* German noun: "tool". Etymology: *werk* ("work"), *zeug* ("stuff") +Werkzeug is a comprehensive `WSGI`_ web application library. It began as +a simple collection of various utilities for WSGI applications and has +become one of the most advanced WSGI utility libraries. +It includes: +- An interactive debugger that allows inspecting stack traces and + source code in the browser with an interactive interpreter for any + frame in the stack. +- A full-featured request object with objects to interact with + headers, query args, form data, files, and cookies. +- A response object that can wrap other WSGI applications and handle + streaming data. +- A routing system for matching URLs to endpoints and generating URLs + for endpoints, with an extensible system for capturing variables + from URLs. +- HTTP utilities to handle entity tags, cache control, dates, user + agents, cookies, files, and more. +- A threaded WSGI server for use while developing applications + locally. +- A test client for simulating HTTP requests during testing without + requiring running a server. +Werkzeug is Unicode aware and doesn't enforce any dependencies. It is up +to the developer to choose a template engine, database adapter, and even +how to handle requests. It can be used to build all sorts of end user +applications such as blogs, wikis, or bulletin boards. +`Flask`_ wraps Werkzeug, using it to handle the details of WSGI while +providing more structure and patterns for defining powerful +applications. %prep -%autosetup -n %{srcname}-%{version} -p1 -Sgit -%{__sed} -i 's/\r//' LICENSE -%{__sed} -i '1d' tests/multipart/test_collect.py -tar -xf %{SOURCE1} -find -name '_themes' -type d -exec cp -r {} docs/ \; - -rm -rf %{py3dir} -cp -a . %{py3dir} -find %{py3dir} -name '*.py' | xargs sed -i '1s|^#!python|#!%{__python3}|' - +%autosetup -n werkzeug-1.0.1 %build -werkzeug_build() { - find examples/ -name '*.py' -executable | xargs chmod -x - find examples/ -name '*.png' -executable | xargs chmod -x - pushd docs - # Add a symlink to the dir with the Python module so that __version__ can be - # obtained therefrom. - ln -s ../werkzeug werkzeug - make html - popd -} - -%py2_build -werkzeug_build - -pushd %{py3dir} %py3_build -werkzeug_build -popd - %install -werkzeug_install() { - %{__rm} -rf docs/_build/html/.buildinfo - %{__rm} -rf examples/cupoftee/db.pyc -} -%py2_install -werkzeug_install - -pushd %{py3dir} %py3_install -werkzeug_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 . %check -PYTHONPATH=./ py.test-2 - -pushd %{py3dir} -PYTHONPATH=./ py.test-3 -popd - -%files -n python2-werkzeug -%license LICENSE AUTHORS -%doc PKG-INFO CHANGES.rst -%{python2_sitelib}/* - -%files -n python2-werkzeug-doc -%doc docs/_build/html examples - -%files -n python3-werkzeug -%license LICENSE AUTHORS -%doc PKG-INFO CHANGES.rst -%{python3_sitelib}/* +PYTHONPATH=%{buildroot}%{python3_sitelib} pytest-3 -%files -n python3-werkzeug-doc -%doc docs/_build/html examples +%files -n python3-werkzeug -f filelist.lst +%dir %{python3_sitelib}/* +%files help -f doclist.lst +%{_docdir}/* %changelog -* Mon Nov 4 2019 openEuler Buildteam - 0.14.1-4 -- Package init +* Thu Feb 04 2021 Python_Bot +- Package Spec generated