On Jul 04, 2011, at 08:20 AM, Robert Collins wrote:
>unittest2 is still a unittest runner at heart; the basic model is
>sound to scale up to N processes and so forth (see tox or
>testrespository for instance), but compatibility with arbitrary ways
>of running is pretty tricky. See for instance the
On Sat, Jul 2, 2011 at 2:07 AM, Barry Warsaw wrote:
>>In some sub-communities, py.test or nosetests are the standard, not
>>setup.py test.
>
> Yes, but if I understand where Michael is taking unittest2, those can just be
> refactored to be plugins instead of separate standards. Then `python setup
Hi,
Le 01/07/2011 16:07, Barry Warsaw a écrit :
> On Jun 15, 2011, at 05:07 PM, Éric Araujo wrote:
>> Yes, last summer’s GSoC added a test command, which defaults to
>> unittest(2) test discovery and can be configured to use any test runner
>> on any test suite. It runs tests against the modules
On Jun 15, 2011, at 02:39 AM, Zygmunt Krynicki wrote:
>I agree in the value but I don't want to assume that it is a default practice
>or requirement. I package/hack on the webapp (django) side of tests and after
>being spoiled with the goodness of python-testtools and python-testscenarios
>I ventu
On Jun 15, 2011, at 05:07 PM, Éric Araujo wrote:
>Yes, last summer’s GSoC added a test command, which defaults to
>unittest(2) test discovery and can be configured to use any test runner
>on any test suite. It runs tests against the modules in the build
>directory, to be able to work with code co
Apologies for the delayed response.
On Jun 15, 2011, at 01:03 AM, Zygmunt Krynicki wrote:
>W dniu 15.06.2011 00:04, Barry Warsaw pisze:
>> On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote:
>>
>>> Can please we have standardized hooks to build sphinx documentation and run
>>> setup.py test tes
* Vincent Bernat , 2011-06-15, 07:31:
On the debian side I always have to copy-paste the same-looking code
over and over again (symlink jquery,
If you use dh_link in your debian/rules (most likely you do), you need
only a single line in debian/.links to do that.
Don't you need to remove jque
Le 15/06/2011 10:18, Zygmunt Krynicki a écrit :
> W dniu 15.06.2011 03:28, Ben Finney pisze:
If we are talking from a perspective of upstream developers that
also maintain their packages then I would *love* to see setup.py
sdist-test and would use it each day.
>>>
>>> ;-)
>>
>> How w
Hi,
[Barry Warsaw]
> [Zygmunt Krynicki]
>> Can please we have standardized hooks to build sphinx documentation and run
>> setup.py test tests?
> I'd like to see the packaging folks address this. Eric is subscribed to this
> list and can probably speak to packaging's take on it, but my preferences
On Wed, Jun 15, 2011 at 10:18:25AM +0200, Zygmunt Krynicki wrote:
> W dniu 15.06.2011 03:28, Ben Finney pisze:
>
> >>>If we are talking from a perspective of upstream developers that
> >>>also maintain their packages then I would *love* to see setup.py
> >>>sdist-test and would use it each day.
>
W dniu 15.06.2011 03:28, Ben Finney pisze:
If we are talking from a perspective of upstream developers that
also maintain their packages then I would *love* to see setup.py
sdist-test and would use it each day.
;-)
How would a putative ‘sdist_test’ differ from ‘test’? Why is this an
argument
OoO En cette nuit striée d'éclairs du mercredi 15 juin 2011, vers 02:46,
Jakub Wilk disait :
>> On the debian side I always have to copy-paste the same-looking code
>> over and over again (symlink jquery,
> If you use dh_link in your debian/rules (most likely you do), you need
> only a single li
Yaroslav Halchenko writes:
> On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
> > Well joke aside you cannot fix the tarball that people release on
> > pypi with half of the test code and data missing just because their
> > MANIFEST.in was flaky.
>
> ;-) And that is when my evil "package from VCS" co
W dniu 15.06.2011 02:46, Jakub Wilk pisze:
* Zygmunt Krynicki , 2011-06-15, 01:03:
In a setup.py world:
$ python setup.py build_sphinx
This is all fine and pretty (thanks to python).
Only if you are happy that your extension modules are built in-place. :/
I did not use extension modules ye
Zygmunt Krynicki writes:
> W dniu 15.06.2011 02:13, Ben Finney pisze:
> >Zygmunt Krynicki writes:
> >> 2) We keep stripping jquery and replacing it with a symlink to
> >> libjs-jquery but we make the process less cumbersome and manual.
Ah, I missed that you were implicitly referring only to Sph
On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
> >oops -- I bluntly believed that we are taking care about both
> >aspects in Debian ;-)
> Well joke aside you cannot fix the tarball that people release on
> pypi with half of the test code and data missing just because their
> MANIFEST.in was flaky.
W dniu 15.06.2011 02:28, Yaroslav Halchenko pisze:
On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
That's different. IHMO you ask for make dist-check AFAIR (my
automake-foo is getting old). Testing installed stuff is often
harder and not supported as we don't want to include tests in the
package (
W dniu 15.06.2011 02:13, Ben Finney pisze:
$ python setup.py test
I would also like this to become the de-facto standard. Can we somehow
make it happen? (debian policy, python something?)3.3).
AFAICT it *is* the de facto standard. Perhaps you mean that you want it
to be the de jure standard
* Zygmunt Krynicki , 2011-06-15, 01:03:
In a setup.py world:
$ python setup.py build_sphinx
This is all fine and pretty (thanks to python).
Only if you are happy that your extension modules are built in-place. :/
On the debian side I always have to copy-paste the same-looking code
over and
On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
> That's different. IHMO you ask for make dist-check AFAIR (my
> automake-foo is getting old). Testing installed stuff is often
> harder and not supported as we don't want to include tests in the
> package (for build-deps vs install-deps). Source layout
Zygmunt Krynicki writes:
> W dniu 15.06.2011 00:04, Barry Warsaw pisze:
> In Python< 3.3, using
> > setuptools/distribute/distutils2, this should be the standard
> > interface:
> >
> > $ python setup.py test
>
> I would also like this to become the de-facto standard. Can we somehow
> make it h
W dniu 15.06.2011 01:06, Yaroslav Halchenko pisze:
ideally I would like to see the helper which would allow (or even by
default would do) to invoke test batteries against just installed (i.e.
python setup.py install) version of the modules: in my experience it
helped to avoid various issues of
W dniu 15.06.2011 00:04, Barry Warsaw pisze:
On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote:
Can please we have standardized hooks to build sphinx documentation and run
setup.py test tests?
I'd like to see the packaging folks address this. Eric is subscribed to this
list and can probab
ideally I would like to see the helper which would allow (or even by
default would do) to invoke test batteries against just installed (i.e.
python setup.py install) version of the modules: in my experience it
helped to avoid various issues of incomplete inclusion of
submodules/data files.
And s
On Jun 14, 2011, at 12:33 PM, Yaroslav Halchenko wrote:
>ah -- wishlist!
Well, just be careful. :) We have to clearly define what's the responsibility
of upstream Python, what falls under third-party add-ons (e.g. Sphinx), and
what is the integrator/OS-vender's responsibility.
>On Tue, 14 Jun 2
On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote:
>Can please we have standardized hooks to build sphinx documentation and run
>setup.py test tests?
I'd like to see the packaging folks address this. Eric is subscribed to this
list and can probably speak to packaging's take on it, but my pref
ah -- wishlist!
On Tue, 14 Jun 2011, Zygmunt Krynicki wrote:
> Can please we have standardized hooks to build sphinx documentation
> and run setup.py test tests? Can those hooks do the right thing with
> generated documentation (dealing all the boring .doc-base files,
> replacing jquery with symli
W dniu 14.06.2011 16:45, Barry Warsaw pisze:
I want to be a conduit between Debian and upstream, so please, I encourage
everyone who has concrete issues that can help the Debian story, to raise them
here. Python is a big ship so it takes time to steer, but as I hope I've
shown with PEP 3147 and
On Jun 14, 2011, at 03:44 PM, Josselin Mouette wrote:
>Le mardi 14 juin 2011 à 07:39 -0400, Barry Warsaw a écrit :
>> Blog references, email threads, or other links to existing artifacts would be
>> very helpful. Has anybody ever written a "What's Wrong With Python and How
>> It
>> Hurts Debian
On Tue, Jun 14, 2011 at 03:44:33PM +0200, Josselin Mouette wrote:
> Le mardi 14 juin 2011 à 07:39 -0400, Barry Warsaw a écrit :
> > Blog references, email threads, or other links to existing artifacts would
> > be
> > very helpful. Has anybody ever written a "What's Wrong With Python and How
>
Le mardi 14 juin 2011 à 07:39 -0400, Barry Warsaw a écrit :
> Blog references, email threads, or other links to existing artifacts would be
> very helpful. Has anybody ever written a "What's Wrong With Python and How It
> Hurts Debian" article?
I have something like that among the things I’d lik
On Jun 14, 2011, at 07:00 PM, Ben Finney wrote:
>I think (as someone with no special authority on Python nor Debian) that
>the people who know most detail about what's painful for packaging
>Python software for Debian are burned out on the topic. They therefore
>don't want to spend the effort to s
Barry Warsaw writes:
> On Jun 10, 2011, at 10:02 AM, Paul Wise wrote:
>
> >Personally I've always wondered why a Debian-specific helper should
> >be needed instead of python upstream behaving the way we wanted.
>
> Can you get more specific about this? Obviously, there's little we can
> do about
33 matches
Mail list logo