Re: [Zope-dev] RFC: adding support for testing from bare setuptools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Tres Seaver wrote: I have checked the proposed changes to 'zope.testing' in on a branch, which I would like to merge to the trunk and release as 3.7: svn+ssh://svn.zope.org/repos/main/zope.testing/branches/tseaver-eggsupport Objections? Hearing none, yesterday I merged the branch to the trunk and tagged a 3.7.0 release. I would like to get the sdist for that uploaded to PyPI, but don't have access. Can one of the maintainers there either grant me access or upload the sdist themselves? That would be one of: srichter, mgedmin, ajung, philikon, J1m, fdrake Seems like this was done already. You should be able to upload the tarball. Now uploaded, thanks. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2k05+gerLs4ltQ4RAv1UAJ90jIiWhW/h1okHI6NyjDuyoKs/gwCdE4IF FdZUuQuxMtD4tmQX8BhOBLA= =C+Iz -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: adding support for testing from bare setuptools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Tres Seaver wrote: I have checked the proposed changes to 'zope.testing' in on a branch, which I would like to merge to the trunk and release as 3.7: svn+ssh://svn.zope.org/repos/main/zope.testing/branches/tseaver-eggsupport Objections? Hearing none, yesterday I merged the branch to the trunk and tagged a 3.7.0 release. I would like to get the sdist for that uploaded to PyPI, but don't have access. Can one of the maintainers there either grant me access or upload the sdist themselves? That would be one of: srichter, mgedmin, ajung, philikon, J1m, fdrake Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2N0N+gerLs4ltQ4RAgLWAJ9caGBeNxnR56tc7NlgDdibGxcEugCgsAsN mPFDnnhL6PXdYZ9IXWIdfuY= =wBYu -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: adding support for testing from bare setuptools
Tres Seaver wrote: Without monkeypatching setuptools, we can't replace the testrunner it uses, Perhaps we can submit a patch to setuptools that allows the testrunner to be specified. I'm sure people using nose, etc, would be happy about this as well and I can't see Phil Eby be too unhappy about trying to help him sort out the mess he's created ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: adding support for testing from bare setuptools
On Thu, Sep 18, 2008 at 12:42:33AM +0200, Philipp von Weitershausen wrote: Marius Gedminas wrote: On Wed, Sep 17, 2008 at 12:52:49PM -0400, Tres Seaver wrote: $ ../bin/python setup.py test # [2] # Runs egg_info, installs regular and testing dependencies, and # runs all unit (non-layer) tests I don't like the idea that running the tests installs additional packages into my environment without me explicitly asking for it. You *are* asking for it by running python setup.py test. I think I got confused (again) by the difference by setuptools and distutils. setuptools has a 'setup.py test' that installs dependencies and runs tests. distutils doesn't have a 'setup.py test' at all. For some reason I thought 'setup.py test' was a distutils thing that didn't know anything about dependencies, and that people who use it were used it not changing the environment. My mistake. Also, python setup.py test doesn't actually install testing dependencies (or any dependencies for that matter) into site-packages. It just dumps them into the CWD. I don't mind that. Marius Gedminas -- This is the Local Descriptor Table, another weird Intel thingy. Linux only uses this for some strange applications like Wine. We don't do anything here, so they'll get an informative and friendly Segmentation Fault. -- lguest source code signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: adding support for testing from bare setuptools
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Gedminas wrote:
On Thu, Sep 18, 2008 at 12:42:33AM +0200, Philipp von Weitershausen wrote:
Marius Gedminas wrote:
On Wed, Sep 17, 2008 at 12:52:49PM -0400, Tres Seaver wrote:
$ ../bin/python setup.py test # [2]
# Runs egg_info, installs regular and testing dependencies, and
# runs all unit (non-layer) tests
I don't like the idea that running the tests installs additional
packages into my environment without me explicitly asking for it.
You *are* asking for it by running python setup.py test.
I think I got confused (again) by the difference by setuptools and
distutils.
setuptools has a 'setup.py test' that installs dependencies and runs
tests.
distutils doesn't have a 'setup.py test' at all.
For some reason I thought 'setup.py test' was a distutils thing that
didn't know anything about dependencies, and that people who use it were
used it not changing the environment.
My mistake.
Also, python
setup.py test doesn't actually install testing dependencies (or any
dependencies for that matter) into site-packages. It just dumps them
into the CWD.
I don't mind that.
I looked again at the patch to the setup.py, and saw some whitespace
fixups in it. Here is the diff for another pacakge without any
housekeeping:
- - % ---
- --- setup.py (revision 91225)
+++ setup.py(working copy)
@@ -42,14 +42,22 @@
include_package_data=True,
namespace_packages=['Products'],
zip_safe=False,
+ setup_requires=['eggtestinfo',
+ ],
install_requires=[
#'Zope = 2.10.4',
'setuptools',
'five.localsitemanager=0.3',
'Products.GenericSetup',
],
+ tests_require=['zope.testing',
+],
+ test_loader='zope.testing.testrunner.eggsupport:SkipLayers',
+ test_suite='Products.%s.tests' % NAME,
entry_points=
[zope2.initialize]
Products.%s = Products.%s:initialize
+ [distutils.commands]
+ ftest = zope.testing.testrunner.eggsupport:ftest
% (NAME, NAME),
)
- - % ---
- - The first change is not strictly required, but it does get the 'test*'
attributes captured in a separate file in the EGG-INFO directory,
which makes it at least theoretically possible to run the tests from
a binary egg (not that I ever use them).
- - The second is what allows 'setup.py test' to work, running only the
non-layer tests. The 'tests_require' part gets zope.testing
downloaded and on the path before looking for the loader specified
in 'test_loader'. That loader then gets passed the 'test_suite'
string.
- - The last section of the diff is what gets a new command available
('setup.py ftest'). That is the part which runs all the tests, both
unit and functional.
If we chose to make the entry point 'test' instead of 'ftest', then
we could leave out the middle section, but would need to make
'zope.testing' a 'setup_requires' dependency. That case is also the one
where running from a fresh checkout requires 'setup.py egg_info' first,
or else the old testrunner gets used the first time. I think that we
are OK for distributed tarballs, because they contain the '.egg-info'
directory generated during 'sdist'.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI0j71+gerLs4ltQ4RAkLGAJ0cHcqrl5AnA6rimuTn9iZyDeuGCACguAJt
wn27D9G/UimUZzcLwUWSncA=
=GVVI
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFC: adding support for testing from bare setuptools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Asbestos - First, note that I am not proposing to replace the current testing machinery used by Zope developers working on a given package (typically, buildout plus recipes which configure zope.testing.testrunner as a standalone script). Nor am I proposing that we modify that machinery to take advantage of setuptools' test-oriented metadata (that would be a separate proposal). Proposal - Instead, what I *am* proposing is adding metadata which allows consumers of such packages to verify that the package is downloaded / installed correctly. In particular, I want for the following scenario to work seamlessly:: $ /path/to/virtualenv --no-site-packges sandbox ... $ cd sandbox $ tar xzf zope.foo.bar-3.5.6.tar.gz $ cd zope.foo.bar-3.5.6 # [1] $ ../bin/python setup.py test # [2] # Runs egg_info, installs regular and testing dependencies, and # runs all unit (non-layer) tests $ ../bin/python setup.py test# [3] # Runs egg_info, installs regular and t # runs *all* tests Theory of Operation - --- [1] Ideally, this would be some variation on 'easy_install' which got the package into the environment in such a way that its 'setup.py' could be run. Fetching and unpacking the tarball manually works today, however ;) [2] 'python setup.py test' is the standard way to test a setuptools-based package, and would be expected to work by most egg-savvy Python developers. setuptools provides the 'test' command, using a built-in testrunner which mostly Just Works(TM). However, it doesn't support the 'layer' feature provided by 'zope.testrunner', and therefore many Zopeish packages emit failures when run this way. Without monkeypatching setuptools, we can't replace the testrunner it uses, but we *can* supply a different test loader using an option in setup.py[4]. The attached module provides such a loader, which filters out the doomed tests, leaving only those which can run cleanly without layers (e.g., the unit tests). [3] In the second method, we use the setuptools entry point mechanism to register a custom 'test' command[5]. This is a wee bit fragile, as running 'setup.py test' without first generating the egg_info will use the standard testrunner (but only the first time). If such fragility is an issue, we can register a separate command, e.g. 'ftest'; in either case, we have to document that you need to run 'setup.py egg_info' one time before running the custom command. If the ideal installation outlined in [1] above worked, that would solve the problem, too, because the egg-info would be generated by easy_install. This techniquie drives the zope.testing.testrunner via an entry point, which is cool, but it cannot expose all of testrunner's features. In particular, the configuration knobs which the testrunner expects to get on the command-line clash with distutils' own command-line syntax (yes, I've tried to make it work). The command I have provided just runs all the tests, unit and functional, which seems to be reasonable assurance for the package conumer that the package installed cleanly. Implementation - -- The intent is to add the attached module as 'zope.testing.testrunner.eggsupport', and then to modify our packages (opportunistically, or through a 'geddon) as follows: - Add 'setup_requires = [eggtestinfo]', so that the testing metadata is captured in EGG-INFO. Note that this information is not needed when running the tests from a source distribution, but should ease a TBD mode for testing binary distributions. - Add 'tests_require = [zope.testing = 3.7]' (or whatever the next released version including this feature would be), to make the loader available. - Add 'test_loader = zope.testing.testrunner.eggsupport:SkipLayers' which enables 'setup.py test' to use the custom loader. Once the new 'zope.testing' package is present, then the 'ftest' command will also be available, but still needs to be called out via an entry point:: entry_points= [distutils.commands] ftest = zope.testing.testrunner.eggsupport:ftest The second attachment is a diff showing the changes to a typical Zope2 product's setup.py to support this proposal. References - -- [4] http://peak.telecommunity.com/DevCenter/setuptools#test-loader [5] http://peak.telecommunity.com/DevCenter/setuptools#adding-commands Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0TXh+gerLs4ltQ4RAuEGAJ411zdUI+GjQZEkPtf2uB1zgX3KeQCgvjlA rHFCcXsSaPpY9AklWGqlmqk= =PbVE -END PGP SIGNATURE- eggsupport.py Description: application/httpd-cgi Index: setup.py
Re: [Zope-dev] RFC: adding support for testing from bare setuptools
On Wed, Sep 17, 2008 at 12:52:49PM -0400, Tres Seaver wrote: Proposal Instead, what I *am* proposing is adding metadata which allows consumers of such packages to verify that the package is downloaded / installed correctly. In particular, I want for the following scenario to work seamlessly:: $ /path/to/virtualenv --no-site-packges sandbox ... $ cd sandbox $ tar xzf zope.foo.bar-3.5.6.tar.gz $ cd zope.foo.bar-3.5.6 # [1] $ ../bin/python setup.py test # [2] # Runs egg_info, installs regular and testing dependencies, and # runs all unit (non-layer) tests I don't like the idea that running the tests installs additional packages into my environment without me explicitly asking for it. $ ../bin/python setup.py test# [3] # Runs egg_info, installs regular and t This is truncated. # runs *all* tests ... [3] In the second method, we use the setuptools entry point mechanism to register a custom 'test' command[5]. This is a wee bit fragile, as running 'setup.py test' without first generating the egg_info will use the standard testrunner (but only the first time). If such fragility is an issue, we can register a separate command, e.g. 'ftest'; in either case, we have to document that you need to run 'setup.py egg_info' one time before running the custom command. (The more I learn about setuptools, the less I like them.) If the ideal installation outlined in [1] above worked, that would solve the problem, too, because the egg-info would be generated by easy_install. This techniquie drives the zope.testing.testrunner via an entry point, which is cool, but it cannot expose all of testrunner's features. In particular, the configuration knobs which the testrunner expects to get on the command-line clash with distutils' own command-line syntax (yes, I've tried to make it work). The command I have provided just runs all the tests, unit and functional, which seems to be reasonable assurance for the package conumer that the package installed cleanly. *nod* Implementation -- The intent is to add the attached module as 'zope.testing.testrunner.eggsupport', At this point I'm wondering whether we shouldn't split out the testrunner into a separate zope.testrunner package. and then to modify our packages (opportunistically, or through a 'geddon) as follows: ... The second attachment is a diff showing the changes to a typical Zope2 product's setup.py to support this proposal. I'm +0.5 for the idea, although the amount of ritual dancing in the setup.py seems a bit excessive. Marius Gedminas -- 99 little bugs in the code, 99 bugs in the code, fix one bug, compile it again... 101 little bugs in the code signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: adding support for testing from bare setuptools
Marius Gedminas wrote: On Wed, Sep 17, 2008 at 12:52:49PM -0400, Tres Seaver wrote: Proposal Instead, what I *am* proposing is adding metadata which allows consumers of such packages to verify that the package is downloaded / installed correctly. In particular, I want for the following scenario to work seamlessly:: $ /path/to/virtualenv --no-site-packges sandbox ... $ cd sandbox $ tar xzf zope.foo.bar-3.5.6.tar.gz $ cd zope.foo.bar-3.5.6 # [1] $ ../bin/python setup.py test # [2] # Runs egg_info, installs regular and testing dependencies, and # runs all unit (non-layer) tests I don't like the idea that running the tests installs additional packages into my environment without me explicitly asking for it. You *are* asking for it by running python setup.py test. Also, python setup.py test doesn't actually install testing dependencies (or any dependencies for that matter) into site-packages. It just dumps them into the CWD. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
