Added a new 'setup.py test' command-line options --pytest-args/-a accepting all
pytest specific command-line arguments as a single whitespace separated string.
For example, the following command will run only tests containing ``binding`` in
their name, will stop on first failure and will automatically drop into Python's
post-mortem debugger on failure::
setup.py test -a "-k binding -x --pdb"
Does not currently support passing pytest specific command-line arguments
containing embedded whitespace.
* made less reliant on its setuptools.command.test.test base class
* better commented its relationship with its base class
* no longer triggers its base setuptools test command's command-line option
processing
* no longer incorrectly reports supporting its base class's command-line options
* no longer incorrectly reports using the 'unittest' framework in its verbose
output
Python 2 versions prior to some early 2.7.x release and Python 3 versions prior
to some 3.2.x release had buggy disutils implementations that can result in our
project's source distribution containing some extra unwanted files picked up
from some of our local 'tools/__*' cache folders. Such extra files are then
explicitly excluded by an explicit 'prune' rule in MANIFEST.in.
However, that can cause spurious warnings in case no such local cache folders
exist or no files have been collected from them. This commit works around the
issue in 2 stages:
1. setup.py always creates one such dummy folder containing a single dummy file
that is guaranteed to always be included on buggy implementations. This
avoids the warning on buggy distutils implementations when no extra files
have been collected.
2. MANIFEST.in explicitly includes the dummy file created by setup.py. This
avoids the warning on working distutils implementations which never collect
any extra files by themselves.
Since the pytest & py packages we used to make our tests run on Python 2.4 are
not formally compatible, we must not explicitly specify pytest as a test
requirement or setuptools will go ahead and verify that all of its formally
specified requirements have been specified and fail.
Duplicate code extracted to new modules under the suds_devel package:
- specifying the project's requirements - requirements.py
- specifying the used setuptool install script - ez_setup_versioned.py
Updated todo list.
The test suite is no longer installed together with the project and can now be
run from the project's source distribution. This resolves the issue of the suds
test suite confusing users by getting installed as a top level tests package in
their Python environment.
Project to be tested now need to be explicitly installed prior to running its
tests using pytest, except in case of Python 2 tests being run from the top
level project folder. This requires the user to install the project (suggested
way is to install it in editable mode using 'pip install -e') but also allows
him to run the tests on other non-sandbox project versions, e.g. an externally
installed version.
Project testing now requires the six Python 2/3 compatibility support package
(installed automatically, together with other test requirements).
Test support code now moved to a separate testutils package located under the
tests folder.
Updated project README.rst & HACKING.rst docs.
Minor stylistic changes.
Before it did not take care of which colorama package (pytest prerequisite) got
installed into such environments, which could cause it to install an
incompatible one.
Code lifted from the tools/setup_basic_environments.py script and this code
duplication should be removed in the future.
Python [3.0, 3.2.2> distutils implementation writes package meta-data using
the user's local environment encoding instead of UTF-8. Since the maintainer's
name contains a non-ASCII character - this can cause problems if the user's
local encoding does not support it. In order to avoid such issues, we convert
the name to a similar ASCII-character-only variant, but now we do so only when
using such older Python 3.x releases.
Python 3.x versions prior to Python 3.2.3 have a bug in their inspect module
causing inspect.getmodule() calls to fail if some module lazy loads other
modules when some of its attributes are accessed. For more detailed information
see Python development issue #13487 (http://bugs.python.org/issue13487).
This occurs when using setuptools to install our project into a Python 3.1
environment. There py.error module seems to do such lazy loading which we force
done here before the setuptools installation procedure to avoid the issue.
Since one of setuptools project's test modules contains a UTF-8 BOM, it will
fail to install cleanly on Python versions [3.0 - 3.2> where the py2to3 tool
will not know how to process such files. 'setuptools' can still be installed by
running its ez_setup.py installation script manually (this will report and
ignore the py2to3 error), but attempting to install it using the
ez_setup.use_setuptools() function causes our whole setup to fail.
An embedded code comment explains how this workaround can be further improved,
should anyone feel so inclined, but for now, we simply report a warning and
instruct the user to install setuptool manually if needed.
Added relevant HACKING docs.
setup.py now exits with a clean error message when run using Python 3.0.
Python 3.0 removed from a list of supported Python versions stored in the
project's meta-data.
setup.py will now attempt to use setuptools if available (there is no version
check for preinstalled setuptools), and if not - attempts to install its own
tested setuptools version after downloading it from PyPI. If all attempts to
use setuptools fail, setup.py will fall back on using distutils with a bit
reduced functionality.
See extensive in-code comments for more detailed information on all the
setuptools related functionality, as well as the rationale behind choosing the
current setuptools usage design.
- now works correctly even on Python 2.4.x where it needs to be careful about
what exact pytest and py library versions it needs to install
- if setup.py test command can not be used, it now reports the reason as its
description (displayed using 'setup.py --help-commands') and as a clear
end-user error message when run
- improved the setup.py test command description when used on Python 3+
- split up the implementation into separate & commented sections
- improved internal implementation comments including the main module docstring
- updated the documented module author
- converted to UTF-8 encoding
- lots of minor stylistic changes
Now using setuptools 1.4.2 with Python 2.4 & 2.5, and using setuptools 3.3 with
later Python versions. This should help avoid installation issues in different
exotic use cases that were once not being handled by setuptools but have since
been corrected.
As noted in an already existing comment, PKG_INFO package distribution metadata
file stores this text with an 8 space indentation and therefore should not be
longer than 72 characters.
PyPI started using HTTPS links on all of its package index pages. Therefore,
there is no longer any simple way to make our setup install its requirement
packages automatically from it unless Python actually supports HTTPS downloads.
May run only the basic test suite, as distutils does not support passing on
arbitrary command-line arguments to its commands. For more detailed control,
user still needs to run the test suite directly using pytest.
Allows running the test suit using Python 3 without first having to install the
whole package.
Regular package distribution now includes the test code. This is required in
order to have the distutils 'test' command be able to do a temporary build when
asked to run the project's test suite using Python 3 (needed in order to run
py2to3 on the project's code base).
README.txt file converted to RST format, but renamed instead of deleted/readded
in order to preserve its history. Minor stylistic changes made to it in the
process.
Reverted setup.py changes other than cleaning up line endings, as they were all
version information related.
Reverted external tag information to avoid versioning confusion between the two
forks. Hopefully, they can get merged in some near future, but for now, having
0.4.1 suds-jurko & 0.4.2 suds-palday tags in the same repository seems like just
asking for accidents to happen.
Such characters were causing problems with the 'distribute' based setup
procedure which erroneously assumes they have been prepared using the user's
local code-page.
Benjamin Dauvergne
Jurko Gospodnetić
Phillip Alday