packages/python-werkzeug
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

upgrade to 1.0.1

Browse Source
This commit is contained in:
zhaorenhai 2021-02-04 09:14:00 +00:00
parent 4bb36b939b
commit 18941ba20e
6 changed files with 149 additions and 272 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
0.14.1.tar.gz
View File

Binary file not shown.

BIN
1.0.1.tar.gz Normal file
View File

Binary file not shown.

133
Skip-tests-that-use-xprocess-fixture-when-not-installed.patch
View File

@ -1,133 +0,0 @@
From 7a4e8b834ee81aeeaa5dd0458b3986d33bb69de8 Mon Sep 17 00:00:00 2001
From: Adam Williamson <awilliam@redhat.com>
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 <awilliam@redhat.com>
---
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):

BIN
Werkzeug-0.14.1.tar.gz
View File

Binary file not shown.

252
python-werkzeug.spec
View File

@ -1,122 +1,168 @@
%global debug_package %{nil}
%global srcname Werkzeug
%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
Name: python-werkzeug
Summary: A comprehensive WSGI web application library
Version: 0.14.1
Release: 8
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
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
# 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
# Fix test fail with python3.8
Patch1: werkzeug-fix-tests-for-nightly-and-osx.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
%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 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
%{__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/ \;
find . -name '*.py' | xargs sed -i '1s|^#!python|#!%{__python3}|'
sed -i "s/'python'/'python3'/ p" tests/test_serving.py
%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
}
%py3_build
werkzeug_build
%install
werkzeug_install() {
%{__rm} -rf docs/_build/html/.buildinfo
%{__rm} -rf examples/cupoftee/db.pyc
}
%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-3
PYTHONPATH=%{buildroot}%{python3_sitelib} pytest-3
%files -n python3-werkzeug
%license LICENSE AUTHORS
%doc PKG-INFO CHANGES.rst
%{python3_sitelib}/*
%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
* Tue Aug 11 2020 zhangjiapeng <zhangjiapeng@huawei.com> - 0.14.1-8
- Remove python2-werkzeug subpackage
* Wed Jun 24 2020 lingsheng <lingsheng@huawei.com> - 0.14.1-7
- Fix test fail with python3.8
* Mon Nov 4 2019 openEuler Buildteam <buildteam@openeuler.org> - 0.14.1-4
- Package init
* Thu Feb 04 2021 Python_Bot <Python_Bot@openeuler.org>
- Package Spec generated

36
werkzeug-fix-tests-for-nightly-and-osx.patch
View File

@ -1,36 +0,0 @@
From e060800e8e6e0c611f9439d746bd4da99a314b79 Mon Sep 17 00:00:00 2001
From: David Lord <davidism@gmail.com>
Date: Tue, 12 Feb 2019 08:32:59 -0800
Subject: [PATCH] fix tests for nightly and osx
---
tests/test_utils.py | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/test_utils.py b/tests/test_utils.py
index 5a6a3f523..6de22b3d5 100644
--- a/tests/test_utils.py
+++ b/tests/test_utils.py
@@ -161,16 +161,16 @@ def test_unescape():
def test_import_string():
- import cgi
+ from datetime import date
from werkzeug.debug import DebuggedApplication
- assert utils.import_string('cgi.escape') is cgi.escape
- assert utils.import_string(u'cgi.escape') is cgi.escape
- assert utils.import_string('cgi:escape') is cgi.escape
+ assert utils.import_string('datetime.date') is date
+ assert utils.import_string(u'datetime.date') is date
+ assert utils.import_string('datetime:date') is date
assert utils.import_string('XXXXXXXXXXXX', True) is None
- assert utils.import_string('cgi.XXXXXXXXXXXX', True) is None
+ assert utils.import_string('datetime.XXXXXXXXXXXX', True) is None
assert utils.import_string(u'werkzeug.debug.DebuggedApplication') is DebuggedApplication
pytest.raises(ImportError, utils.import_string, 'XXXXXXXXXXXXXXXX')
- pytest.raises(ImportError, utils.import_string, 'cgi.XXXXXXXXXX')
+ pytest.raises(ImportError, utils.import_string, 'datetime.XXXXXXXXXX')
def test_import_string_attribute_error(tmpdir, monkeypatch):