On Wed, Jan 6, 2010 at 6:13 PM, Tarek Ziadé wrote:

Hello,

Besides the PEP-related features, I would like to add some tiny features in Distutils for Python 2.7 before the alpha stage is over :

- a test command, that just uses the new unittest discovery to run unittest-compatible tests.

- a new option for sdist called 'extra_files', that will allow to list extra files to be included in the distribution. these  files will not be installed by 'install', just be part of the distribution.

Ooops forgot the third one, (which might lead to further discussions): - a very basic pre/post commit hook for the install command. Tarek

On Wed, Jan 6, 2010 at 12:13 PM, Tarek Ziadé wrote:

- a new option for sdist called 'extra_files', that will allow to list extra files to be included in the distribution. these  files will not be installed by 'install', just be part of the distribution.

Any comments ?

Would this replace the need for MANIFEST.in? If not, what would MANIFEST.in still be used for?

Hi Tarek On Wed, Jan 06, 2010 at 06:13:21PM +0100, Tarek Ziadé wrote:

Besides the PEP-related features, I would like to add some tiny features in Distutils for Python 2.7 before the alpha stage is over :

- a test command, that just uses the new unittest discovery to run unittest-compatible tests.

Will it be easy to change this to use py.test or nose? Or will that just be the normal command overriding mechanism? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

On Thu, Jan 07, 2010 at 04:25:52PM +0100, Tarek Ziadé wrote:

On Thu, Jan 7, 2010 at 1:44 PM, Floris Bruynooghe wrote:

...

Hi Tarek

On Wed, Jan 06, 2010 at 06:13:21PM +0100, Tarek Ziadé wrote:

...

Besides the PEP-related features, I would like to add some tiny features in Distutils for Python 2.7 before the alpha stage is over :

- a test command, that just uses the new unittest discovery to run unittest-compatible tests.

Will it be easy to change this to use py.test or nose?  Or will that just be the normal command overriding mechanism?

Are you referring to Setuptools' test_suite option ?

No, since I don't know this option.

Distutils test command could have a similar mechanism, but without the auto-installation machinery that comes with Setuptools' one, or the entry points. e.g. running test will not install a third-party package, and will not do a plugin discovery. So one may pass the name of a module or method, like "nose.collector" for delegating the test collecting.

Auto-installation definitely seems crazy. But delegating the test collecting and test run might be sensible. I was just wondering for the case where the package developer uses nose or py.test and a user just goes for the default "python setup.py test" which then could produce strange and hard to understand errors. So by allowing the developer to specify e.g. py.test as test collector/runner the users would either have the correct test runner installed and it works, or would get a meaningful error message like "py.test testrunner missing".

But is there a real use case for that ? I mean, you use Nose, can't you just run nosetests in the root ?

Sure, but by making it built into distutils (which is a good thing btw) users will use it even if the developer uses notetests. Because no one reads the README's. ;-)

Or is this for avoing a PATH manipulation on win32 systems ? where sys.prefix+/Scripts is not in PATH.

No idea what specific windows problems would be, sorry. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org