We want the test subprocesses to use the same sys.path as its calling process.
However, our test subprocesses get run in a different folder so we need to
manually convert any empty-string sys.path entries to the current folder path
before passing that sys.path off to a new test subprocess.
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.
Installs packages into multiple Python environments so they can be used for
testing this project. This automates all the previously manually done work on
setting up those environments.
The script contains a multitude of open TODO comments and should still be
considered 'work in progress', but successfully gets the work done at least on
one Windows 7 x64 SP1 machine with 17 different parallel Python installations.
Updated relevant HACKING.rst docs.
Relevant configuration added to the main project Python configuration file
'setup.cfg'.
All Python modules indended for use in different project development utility
scripts have been placed under the suds_devel package folder located under the
tools project folder.
The new scripts:
- are included in the project's source distribution,
- are not installed with the project
- do not need py2to3 processing
- do not have any tests of their own yet
tools/__* folders get created and used as local caches by the new
tools/setup_base_environments.py development script and so must not included in
the project's source distribution.
Files & folders starting '__' are temporary or cache artefacts produced by
either Python (e.g. '__pycache__' folders) or our internal development tools.
*.egg/*.gz/*.zip files may be downloaded by setup.py when running its develop/install/test commands.
*.egg-info folder gets created by setup.py when running its
build/develop/egg_info/install/test commands.
Note that setting up some of the supported older Python environments requires
manual tweaking that has not yet been automated anywhere or described in detail
in the project's HACKING docs.
All sections now linked to from the top of the file.
The whole document will require further work, but for now, at least the
sections are consistently named, separated & linked to (even if they are not yet
positioned in a completely logical order).
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.
py2to3 does not support reading source files with an explicitly specified UTF-8
BOM prior to Python 3.2. This was causing errors when using it to process two
of our project files.
Updated relevant HACKING.rst documentation.
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.
When using a pip to install our product into a Python environment with an
existing setuptools installation older than the one used in our project - the
installation will fail and require that the user manually upgrade the existing
setuptools installation.
The issue has already been fixed in the current development version by no longer
requiring a specific setuptools version.
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
Operations such as setup.py support for uploading a new project distribution
package to PyPI need to be supported on the latest Python 2 & 3 releases only
and no additional backward compatibility is either tested or guaranteed for
them.
* documented the minimum required pytest version - 2.4.0
* noted the display problems when running tests using Python 2.4 on Windows
* added more detailed notes on setting up the Python 2.4.3 project development
environment
* removed some duplicate content
* stylistic cleanup
Jurko Gospodnetić
Matthew Duggan