entrouvert
/
debian-suds-jurko
17
0
Fork 0
Code Issues Pull Requests Releases Activity

Cleanup before the initial forked project release. 

* Renamed internal HACKING, LICENSE, README & TODO documentation files to use
  the .txt extension and thus be easier to use on Windows.
* Renamed the forked project name to 'suds_jurko' to differentiate it from the
  original 'suds' project on PyPI.
* Added a MANIFEST.in project configuration file listing the forked project's
  source distribution content (needed since we are using the Mercurial version
  control system and our installation packager does not know how to
  automatically collect 'all files under Mercurial version control' the way it
  does for CVS or SVN).
* Improved project documentation.
    * More detailed 'setup.py' usage documentation notes (HACKING.txt).
    * Documented the forked project's release procedure (HACKING.txt).
    * Documented the forked project's release download locations (README.txt).
    * Documented the forked project's installation procedure (README.txt).
* Preparing source distributions ('setup.py sdist') now configured to be use the
  .tar.bz2 format by default as it takes the least space.
* Updated the forked project's meta data used when preparing distribution
  packages (description, long_description, keywords, url, download_url, ...).
* Project's built distribution no longer contains test.* subpackages.
* Updated todo list.
This commit is contained in:
Jurko Gospodnetić 2011-12-24 12:35:41 +01:00
parent 3d08084e0d
commit 571424f78b
9 changed files with 309 additions and 91 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.hgignore
View File

@ -3,7 +3,7 @@ syntax: regexp
# Root folders - 'setup.py install' artifacts.
^build/
^dist/
^suds\.egg-info/
^[^/]+.egg-info/
# Precompiled Python modules.
/__pycache__$

58
HACKING
View File

@ -1,58 +0,0 @@
GENERAL DEVELOPMENT NOTES:
=================================================
* Project's sources accessible from a Mercurial version control repository
hosted by BitBucket at 'https://bitbucket.org/jurko/suds'.
* Project development should be tracked in the TODO file.
* Exact formatting is not important as long as its contect is kept
formatted consistently.
* Done tasks should be marked as such and not deleted.
* Testing.
* 'pytest' testing framework needed to run unit tests.
* To run the tests using Python 3 first process them and the rest of the
library sources using the Python 2to3 conversion tool.
* Base sources should remain Python 2.x compatible. Since the original
project states aiming for Python 2.4 compatibility we should do so as
well.
* Python 3 related patches applicable to the original suds development
project.
* Should be first be added to the 'Python 3 support' branch and then
merged back to the trunk from there.
* Should be kept synchronized with the ones found in the Mercurial patch
queue hosted at 'https://bitbucket.org/bernh/suds-python-3-patches'.
TOP-LEVEL FILES & FOLDERS:
=================================================
* '.hg/', '.hgignore', '.hgtags'.
* Mercurial version control related data.
* 'build/', 'dist/', 'suds.egg-info/'.
* Folders created during project setup procedure (build + install).
* 'suds/'.
* Basic project source code.
* 'tests/'.
* Project test code.
* '.project', '.pydevproject', 'makefile', 'python-suds.spec', 'sdist'.
* Original suds library development project's development environment
configuration & scripts as used by the original developer.
* 'HACKING', 'LICENSE', 'README', 'TODO'.
* Internal project documentation.
* 'setup.cfg'.
* Basic project Python configuration.
* 'setup.py'.
* Standard Python project setup script.
* Use 'setup.py --help' for more details.
* 'setup.py build' for building the project.
* 'setup.py install' for builing & installing the project.

100
HACKING.txt Normal file
View File

@ -0,0 +1,100 @@
GENERAL DEVELOPMENT NOTES:
=================================================
* Project's sources accessible from a Mercurial version control repository
hosted by BitBucket at 'https://bitbucket.org/jurko/suds'.
* Project development should be tracked in the TODO.txt file.
* Exact formatting is not important as long as its contect is kept
formatted consistently.
* Done tasks should be marked as such and not deleted.
* Testing.
* 'pytest' testing framework needed to run unit tests.
* To run the tests using Python 3 first process them and the rest of the
library sources using the Python 2to3 conversion tool.
* Base sources should remain Python 2.x compatible. Since the original
project states aiming for Python 2.4 compatibility we should do so as
well.
* Python 3 related patches applicable to the original suds development
project.
* Should be first be added to the 'Python 3 support' branch and then
merged back to the trunk from there.
* Should be kept synchronized with the ones found in the Mercurial patch
queue hosted at 'https://bitbucket.org/bernh/suds-python-3-patches'.
TOP-LEVEL FILES & FOLDERS:
=================================================
* '.hg/', '.hgignore', '.hgtags'.
* Mercurial version control related data.
* 'build/', 'dist/', 'suds_jurko.egg-info/'.
* Folders created during project setup procedure (build + install).
* 'suds/'.
* Basic project source code.
* 'tests/'.
* Project test code.
* '.project', '.pydevproject', 'makefile', 'python-suds.spec', 'sdist'.
* Original suds library development project's development environment
configuration & scripts as used by the original developer.
* 'MANIFEST.in'.
* Build system configuration file listing the files to be included in
the project's source distribution packages in addition to those
automatically added to those packages by the used package preparation
system.
* 'HACKING.txt', 'LICENSE.txt', 'README.txt', 'TODO.txt'.
* Internal project documentation.
* 'setup.cfg'.
* Basic project Python configuration.
* 'setup.py'.
* Standard Python project setup script.
* Use 'setup.py --help' for more details.
* 'setup.py build' for building the project.
* 'setup.py develop' for preparing the development environment
(adding the project folder to the Python module search path).
* 'setup.py install' for builing & installing the project.
* 'setup.py register' for registering a project release at PyPI.
* 'setup.py sdist' for preparing a source distribution.
* 'setup.py upload' for uploading prepared packages to PyPI.
RELEASE PROCEDURE:
=================================================
* Version identification.
* Remove the '(development)' suffix for official release builds.
* Format '<base-suds-version> jurko #'.
* E.g. '0.4.1 jurko 1'.
* Tag in Hg.
* Name the tag like 'release-<version-info>'.
* E.g. 'release-0.4.1 jurko 1'.
* Prepare official releases based only on tagged commits.
* Note.
* Official releases should always be prepared based on tagged
revisions with no local changes in the used sandbox.
* Prepare source distribution packages (both .zip & .tar.bz2 formats),
register the new release at PyPI and upload the prepared source
packages.
* Run 'setup.py sdist register upload'.
* Upload the prepared source package to the project site.
* Use the BitBucket project web interface.
* Optionally archive the prepared source package locally.
* Next development version identification.
* Bump up the forked project version counter.
* Add back the '(development)' suffix.
* Notify whomever the new release might concern.

0
LICENSE → LICENSE.txt
View File

21
MANIFEST.in Normal file
View File

@ -0,0 +1,21 @@
# Additional files to be included in the source distribution package (created
# by running 'setup.py sdist'). Theoretically we could avoid having to manually
# maintain this list by using a setuptools plugin that would automatically
# include all files under Mercurial version control, but the setuptools_hg we
# tried out did not work correctly with Python 3.
# Top level project files.
include .hgignore
include .hgtags
include .project
include .pydevproject
include HACKING.txt
include LICENSE.txt
include makefile
include python-suds.spec
include README.txt
include sdist
include TODO.txt
# Test scripts explicitly not included in non-source distribution packages.
recursive-include tests *.py

34
README → README.txt
View File

@ -2,7 +2,7 @@ OVERVIEW:
=================================================
"Suds" is a lightweight SOAP-based web service client for Python licensed
under LGPL (see the LICENSE file included in the distribution).
under LGPL (see the LICENSE.txt file included in the distribution).
This is hopefully just a temporary fork of the original suds Python library
project created because the original project development seems to have stalled.
@ -11,15 +11,40 @@ again.
Forked project information:
* Project site: https://bitbucket.org/jurko/suds
* Epydocs documentation: needs to be built from sources.
* Epydocs documentation: needs to be built from sources
* Official releases can be downloaded from:
* PyPI - 'http://pypi.python.org/pypi/suds-jurko'
* BitBucket - 'https://bitbucket.org/jurko/suds/downloads'
Original suds Python library development project information:
* Project site: https://fedorahosted.org/suds
* Documentation: https://fedorahosted.org/suds/wiki/Documentation
* Epydocs: http://jortel.fedorapeople.org/suds/doc
For development notes see the HACKING document included in the distribution.
For development notes see the HACKING.txt document included in the
distribution.
INSTALLATION:
=================================================
Standard Python installation.
Here are the basic instructions for 3 different installation methods:
Using pip:
* Have the pip package installed.
* Run 'pip install suds-jurko'.
Using easy-install:
* Have the 'distribute' package installed.
* Run 'easy_install suds-jurko'.
From sources:
* Unpack the source package somewhere.
* Run 'python setup.py install' from the source distribution's top level
folder.
RELEASE NOTES:
=================================================
@ -72,7 +97,8 @@ version 0.4.1 jurko 1 (2011-12-22)
* Separated standalone tests from those requiring an external web
service.
* Added additional unit tests.
* Added development related documentation - HACKING.
* Added development related documentation - HACKING.txt.
* Setup procedure cleaned up a bit.
ORIGINAL SUDS LIBRARY RELEASE NOTES:

102
TODO → TODO.txt
View File

@ -32,23 +32,66 @@ PRIORETIZED:
(+) * 'relavent' --> 'relevant'.
(+) * 'indicat' --> 'inidcat'.
* (Jurko) Prepare for the initial forked project release.
* Research release procedure.
* How to prepare a source distribution package.
* How to upload the prepared distribution packages.
* BitBucket.
* PyPI.
* Document how to access this forked project's development sources &
released files.
* Released project packages accessible from PyPI.
* Installing the project using distribute or pip.
* Document release procedure.
* Version identification.
* Use '(development)' suffix for non-release builds.
* Format 'base-suds-version jurko #', e.g. '0.4.1 jurko 1'.
* Download package at the project site.
* PyPI.
* Tag in Hg.
(22.12.2011.)
(+) * (Jurko) Prepare for the initial forked project release.
(+) * Rename top level project documentation files to use the .txt extension
(+) to make them friendlier to Windows users.
(+) * Research release procedure.
(+) * Open PyPI account.
(+) * How to prepare a source distribution package.
(+) * Change author information.
(+) * Include tests.
(+) * Include all the top-level documentation files.
(+) * 'README'.
(+) * 'LICENSE'.
(+) * 'HACKING'.
(+) * 'TODO'.
(+) * Note the original project author in the package description.
(+) * Include correct license information.
(+) * See what the difference between author and maintainer
(+) information is and where it can be seen.
(+) * Try using 'setuptools_hg' to simplify specifying the project
(+) sources.
(+) * Failed when used under Python 3.
(+) * How to upload the prepared distribution packages.
(+) * Should upload a source distribution only.
(23.12.2011.)
(+) * (Jurko) Prepare for the initial forked project release.
(+) * Research release procedure.
(+) * How to upload the prepared distribution packages.
(+) * PyPI.
(24.12.2011.)
(+) * (Jurko) Prepare for the initial forked project release.
(+) * Research release procedure.
(+) * How to upload the prepared distribution packages.
(+) * BitBucket.
(+) * Document the project's official download URL.
(+) * Document how to access this forked project's development sources &
(+) released files.
(+) * Released project packages accessible from PyPI & BitBucket.
(+) * Installing the project using distribute or pip.
(+) * Document release procedure.
(+) * Version identification.
(+) * Remove the '(development)' suffix for official release builds.
(+) * Format '<base-suds-version> jurko #', e.g. '0.4.1 jurko 1'.
(+) * Tag in Hg.
(+) * Name the tag like 'release-<version-info>', e.g.
(+) 'release-0.4.1 jurko 1'.
(+) * Prepare official releases based only on tagged commits.
(+) * Prepare source distribution package, register the new release
(+) at PyPI and upload the prepared source package.
(+) * Run 'setup.py sdist register upload'.
(+) * Upload the prepared source package to the project site.
(+) * Archive the prepared source release locally if needed.
(+) * Next development version identification.
(+) * Bump up the forked project version counter.
(+) * Add back the '(development)' suffix.
(+) * Commit all local changes.
* (Jurko) Constructing a SOAP request containing data stored in a sequence
inside a choice.
@ -69,9 +112,12 @@ PRIORETIZED:
* Add related test.
* (Jurko) Prepare '0.4.1 jurko 1' release.
* Tag in Hg.
* Download package at the project site.
* PyPI.
* Follow the documented release procedure.
* Update version information.
* Tag in Hg.
* Upload the source package.
* Project site.
* PyPI.
NON PRIORETIZED:
@ -95,11 +141,25 @@ NON PRIORETIZED:
* Test how optional elements under a choice work.
* There are some comments & an additional patch related to this at
'https://fedorahosted.org/suds/ticket/342'.
* Research default values.
* Default element values.
* What they actually mean.
* How elements with default values inside a choice structure should
be handled.
* See what the suds.sudsobjects.Facade class is for.
* How to implement test cases requiring a test web service.
* See how to connect to a web service through a Proxy server requiring
NTLM authentication.
* There are some projects seen on the net implementing a NTLM
authentication handler for urllib.
* Testing this will require implementing a proxy server requiring
NTLM authentication and a web service or at least a web service
requiring NTML authentication.
* Using pylint.
* Implement an urllib connection handler allowing connecting using HTTPS
with client authentication.
* Prepare a test (will require a test web service).
* Implement.
* Prepare additional test cases.
* Prepared SOAP operation invocation requests.

5
setup.cfg
View File

@ -7,6 +7,11 @@
# with missing .pyo files when building rpms with Python 2.4.
optimize = 1
[sdist]
# '.tar.bz2' source distribution format takes the least space while '.zip' is
# the only format supported out-of-the-box on Windows.
formats = bztar,zip
# ----------------------------------
# --- Test related configuration ---

78
setup.py
View File

@ -1,4 +1,5 @@
#!/usr/bin/python
# -*- coding: cp1250 -*-
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the (LGPL) GNU Lesser General Public License as
@ -19,6 +20,8 @@
import os
import os.path
import sys
import pkg_resources
from setuptools import setup, find_packages
# Setup documentation incorrectly states that it will search for packages
@ -58,7 +61,7 @@ exec(open(os.path.join("suds", "version.py"), "rt").read())
extra = {}
if sys.version_info >= (3,0):
extra['use_2to3'] = True
extra["use_2to3"] = True
# Teach Python's urllib lib2to3 fixer that the old urllib2.__version__
# data member is now stored in the urllib.request module.
@ -68,15 +71,76 @@ if sys.version_info >= (3,0):
x[1].append("__version__")
break;
# Wrap long_description at 72 characters since PKG-INFO package distribution
# metadata file stores this text with an 8 space indentation.
long_description = """
---------------------------------------
Lightweight SOAP client (Jurko's fork).
---------------------------------------
Based on the original 'suds' project by Jeff Ortel (jortel at redhat
dot com) hosted at 'https://fedorahosted.org/suds'.
"""
package_name = "suds-jurko"
version_tag = pkg_resources.safe_version(__version__)
project_url = "https://bitbucket.org/jurko/suds"
base_download_url = project_url + "/downloads"
download_distribution_name = "{}-{}.tar.bz2".format(package_name, version_tag)
download_url = "{}/{}".format(base_download_url, download_distribution_name)
packages_excluded_from_build = []
# We generally do not want the tests package or any of its subpackages
# included in our non-source package builds (source distribution content gets
# specified separately by the MANIFEST.ini configuration file). Comment out the
# following line to include the test code anyway, e.g. if you want to run
# Python 3 based tests from the package build folder.
packages_excluded_from_build += ["tests", "tests.*"]
setup(
name="suds",
name=package_name,
version=__version__,
description="Lightweight SOAP client",
description="Lightweight SOAP client (Jurko's fork)",
long_description=long_description,
keywords=["SOAP", "web", "service", "client"],
url=project_url,
download_url=download_url,
obsoletes=["suds"],
setup_requires=["distribute"],
tests_require=["pytest"],
packages=find_packages(exclude=packages_excluded_from_build),
# 'maintainer' will be listed as the distribution package author.
author="Jeff Ortel",
author_email="jortel@redhat.com",
maintainer="Jeff Ortel",
maintainer_email="jortel@redhat.com",
packages=find_packages(exclude=["tests"]),
url="https://fedorahosted.org/suds",
maintainer="Jurko Gospodnetiæ",
maintainer_email="jurko.gospodnetic@pke.hr",
# See PEP-301 for the classifier specification. For a complete list of
# available classifiers see
# 'http://pypi.python.org/pypi?%3Aaction=list_classifiers'.
classifiers=["Development Status :: 5 - Production/Stable",
"Intended Audience :: Developers",
"License :: OSI Approved :: "
"GNU Library or Lesser General Public License (LGPL)",
"Natural Language :: English",
"Operating System :: OS Independent",
"Programming Language :: Python",
"Programming Language :: Python :: 2",
"Programming Language :: Python :: 2.4",
"Programming Language :: Python :: 2.5",
"Programming Language :: Python :: 2.6",
"Programming Language :: Python :: 2.7",
"Programming Language :: Python :: 3",
"Programming Language :: Python :: 3.0",
"Programming Language :: Python :: 3.1",
"Programming Language :: Python :: 3.2",
"Topic :: Internet"],
# PEP-314 states that if possible license & plaform should be specified
# using 'classifiers'.
license="(specified using classifiers)",
platforms=["(specified using classifiers)"],
**extra
)