Many thanks to Bouke Haarsma (bouke at BitBucket) & Ezequiel Ruiz (emruiz81 at
BitBucket) for detecting and reporting the issue as well as to Bouke Haarsma for
preparing a suitable test case and the initial patch.
suds.reader.DocumentReader passes suds.sax.document.Document instances to the
cache which then get silently ignored.
The bug was introduced in one of the final commits in the original suds project
(around the end of 2011) where suds.sax.document.Document class was refactored
to no longer inherit from suds.sax.element.Element.
To maintain backward compatibility, for now we still expect to support passing
suds.sax.element.Element instances to suds.cache.DocumentCache.put() even though
it seems the rest of the suds implementation never does this.
Originally the tests were prepared based on the current DocumentCache.put()
which appears to accept only suds.sax.element.Element instances as input.
However, after reviewing the original suds project and the current suds
implementation, it seems that this is actually a suds bug and that it should
accept suds.sax.document.Document instances instead.
Without this, suds.reader.DocumentReader passes suds.sax.document.Document
instances to the cache which then get silently ignored.
The bug was introduced in one of the final commits in the original suds project
(around the end of 2011) where suds.sax.document.Document class was refactored
to no longer inherit from suds.sax.element.Element.
To maintain backward compatibility, for now we still expect to support passing
suds.sax.element.Element instances to suds.cache.DocumentCache.put() even though
it seems the rest of the suds implementation never does this.
Document instances knew how to convert themselves to their unicode
representation but reported some generic class description string when asked to
convert to a str instance on Python 2.
Bug originally introduced when replacing all __str__() methods with the Unicode
Mixin class.
Many thanks to Ezequiel Ruiz (emruiz81 at BitBucket) for detecting and reporting
the issue.
For now just tests:
- basic Element construction,
- construction name parameter handling
- childAtPath() method
Updated todo list, including adding many new todo items related to adding new
tests.
Brown paper bag fix for a typo introduced when doing code cleanup in a previous
commit affecting this module.
Many thanks to bgr_@bitbucket for catching and reporting this.
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
Now uses the same list of Python environments as used by
'tools/setup_base_environments.py' stored inside the project's main
configuration file 'setup.cfg'.
Updated todo list.
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.
This work is done as a part of preparing the code base to make it reusable in
the planned tools/run_all_tests.cmd Python port as there exactly the same
Environment objects will need to be created.
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.
As before, configured project test environment startup commands use the '.cmd'
suffix as that matches the startup commands used on the current maintainer's
notebook, but now that suffix is no longer hardcoded and is explicitly specified
in the project's configuration file instead.
This work is done as a part of preparing the code base to make it reusable in
the planned tools/run_all_tests.cmd Python port as there Environment objects
will only be used to run the project test suite in a specific Python environment
and will not require additional data collected about that environment.
Now stores its script folder, project folder & ini file paths instead of having
each of its derived classes process that configuration for themselves.
This work is done as a part of preparing the code base to make it reusable in
the planned tools/run_all_tests.cmd Python port.
Since we import too many functions from the suds_devel.utility module, it seems
cleaner to import the module and use its functions by referencing them using an
explicit module prefix instead of importing each one of those functions
explicitly into the local namespace.
The MANIFEST.in file gets processed so that rules in later lines override those
read from earlier ones, meaning we need to add files to the project's source
distribution before we specify that nothing should be added from internal
'tools/__*' cache folders.
pytest 2.6.0 restores Python 3.1 compatibility that has been causing our project
testing to fail in that environment. Note that pytest 2.6.0 has not yet been
officially released but our project's testing has been tried out and found to be
working with the current pytest development tip.
Tested using both the 'setup.py test' command and the
'tools/setup_basic_environments.py' script.
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.
Jurko Gospodnetić
Augusto Destrero