From njriley at uiuc.edu  Sat Jul  1 06:59:58 2006
From: njriley at uiuc.edu (Nicholas Riley)
Date: Fri, 30 Jun 2006 23:59:58 -0500
Subject: [py-dev] requiring options; handling crashes
Message-ID: <20060701045958.GB52122@uiuc.edu>

Hi,

I am starting a new project and and am attempting to give this
test-development development thingy a try, so I am starting to use
py.test.  So far I'm finding it really natural and easy to understand
- especially compared with my short but unhappy experiences with
unittest writing tests for the Metakit Python binding.

I have a few questions.

First, is there a way to enforce options?  For some of the tests I am
using Psyco, which does not play happily with py.test without
--nomagic, so I would like to require this option.  I have tried
something like this in conftest.py:

	import py

	py.test.Config.parse(['--nomagic', '--nocapture', '--exitfirst'])

but that doesn't seem to work, and I'm not sure if there is supposed
to be a way.

Second, some of my tests crash the interpreter, so I'd prefer to test
every file individually (it's fine if no more tests run after the
crash :).  Is there a sensible way to nest py.test invocations such
that the results are aggregated?

If the above aren't possible at the moment, I would be interested in
implementing them; any hints as to a good design or where the code
should go would be appreciated.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>


From hpk at trillke.net  Sun Jul  2 07:47:54 2006
From: hpk at trillke.net (holger krekel)
Date: Sun, 2 Jul 2006 07:47:54 +0200
Subject: [py-dev] requiring options; handling crashes
In-Reply-To: <20060701045958.GB52122@uiuc.edu>
References: <20060701045958.GB52122@uiuc.edu>
Message-ID: <20060702054754.GB5737@solar.trillke>

Hi Nicholas, 

you have two valid points - but i can't satisfyingly answer 
them right now.  Brief notes: 

* option parsing: please look at py/documentation/conftest.py 
  which adds options.  

* crashing interpreters: indeed, we should think about 
  how to run per-module interpreters.  There are hacks 
  for this (in pypy) but we need to think about a clean
  design. 

best, 

    holger

On Fri, Jun 30, 2006 at 23:59 -0500, Nicholas Riley wrote:
> Hi,
> 
> I am starting a new project and and am attempting to give this
> test-development development thingy a try, so I am starting to use
> py.test.  So far I'm finding it really natural and easy to understand
> - especially compared with my short but unhappy experiences with
> unittest writing tests for the Metakit Python binding.
> 
> I have a few questions.
> 
> First, is there a way to enforce options?  For some of the tests I am
> using Psyco, which does not play happily with py.test without
> --nomagic, so I would like to require this option.  I have tried
> something like this in conftest.py:
> 
> 	import py
> 
> 	py.test.Config.parse(['--nomagic', '--nocapture', '--exitfirst'])
> 
> but that doesn't seem to work, and I'm not sure if there is supposed
> to be a way.
> 
> Second, some of my tests crash the interpreter, so I'd prefer to test
> every file individually (it's fine if no more tests run after the
> crash :).  Is there a sensible way to nest py.test invocations such
> that the results are aggregated?
> 
> If the above aren't possible at the moment, I would be interested in
> implementing them; any hints as to a good design or where the code
> should go would be appreciated.
> 
> -- 
> Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
merlinux GmbH       Steinbergstr. 42    31139 Hildesheim   
http://merlinux.de  tel +49 5121 20800 75 (fax 77) 


From brian at dorseys.org  Thu Jul  6 19:06:51 2006
From: brian at dorseys.org (Brian Dorsey)
Date: Thu, 6 Jul 2006 10:06:51 -0700
Subject: [py-dev] Fwd: [py-svn] r29699 - in py/dist/py/test: . testing
In-Reply-To: <20060706164521.0A4BD1009B@code0.codespeak.net>
References: <20060706164521.0A4BD1009B@code0.codespeak.net>
Message-ID: <66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>

---------- Forwarded message ----------
> From: hpk at codespeak.net <hpk at codespeak.net>
<snip>
> Log:
> refine recursive and file filters for directories.
> follow the documentaiton (thanks to Fijal for pointing
> at the documentation inconsistency, i think that
> the 'whatever_test.py' convention is not actually used much)

Hmm... I use the 'whatever_test.py' format for all of my tests. I
admit, that I'm a bit strange, but somehow I like having the test
files right next to the module files since I always edit them in
pairs. Using the test_whatever.py format, all of the tests get sorted
together rather than right next to the files they are actually a test
of.

But, like I said, I'm a bit strange... I think most people like to
keep their tests in a separate directory?

Take care,
  -Brian


From hpk at trillke.net  Fri Jul  7 07:32:50 2006
From: hpk at trillke.net (holger krekel)
Date: Fri, 7 Jul 2006 07:32:50 +0200
Subject: [py-dev] Fwd: [py-svn] r29699 - in py/dist/py/test: . testing
In-Reply-To: <66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>
References: <20060706164521.0A4BD1009B@code0.codespeak.net>
	<66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>
Message-ID: <20060707053250.GN5737@solar.trillke>

Hi Brian!

On Thu, Jul 06, 2006 at 10:06 -0700, Brian Dorsey wrote:
> ---------- Forwarded message ----------
> > From: hpk at codespeak.net <hpk at codespeak.net>
> <snip>
> > Log:
> > refine recursive and file filters for directories.
> > follow the documentaiton (thanks to Fijal for pointing
> > at the documentation inconsistency, i think that
> > the 'whatever_test.py' convention is not actually used much)
> 
> Hmm... I use the 'whatever_test.py' format for all of my tests. I
> admit, that I'm a bit strange, but somehow I like having the test
> files right next to the module files since I always edit them in
> pairs. 
>
> Using the test_whatever.py format, all of the tests get sorted
> together rather than right next to the files they are actually a test
> of.

good point and actually the original one for introducing the 
whatever_test.py pattern. 
 
> But, like I said, I'm a bit strange... I think most people like to
> keep their tests in a separate directory?

yes, most do, i guess.  Nothing strange about not doing 
it - at least i am doing it myself as well. 

I was doing the change also to see if there is anyone
complaining.  I didn't have a plan for when that happens :)

OK, so what now?  I guess reverting to the old behaviour 
and documenting it (the complaint yesterday was that 
the "whatever_test" was not documented).  Could you do
that, Brian? I am still at a pypy sprint (grabbing my
first coffee and such) etc

best, 

    holger


From brian at dorseys.org  Fri Jul  7 20:38:03 2006
From: brian at dorseys.org (Brian Dorsey)
Date: Fri, 7 Jul 2006 11:38:03 -0700
Subject: [py-dev] Fwd: [py-svn] r29699 - in py/dist/py/test: . testing
In-Reply-To: <20060707053250.GN5737@solar.trillke>
References: <20060706164521.0A4BD1009B@code0.codespeak.net>
	<66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>
	<20060707053250.GN5737@solar.trillke>
Message-ID: <66e877b70607071138o6778e84er5afe037d815f18a8@mail.gmail.com>

On 7/6/06, holger krekel <hpk at trillke.net> wrote:
> OK, so what now?  I guess reverting to the old behaviour
> and documenting it (the complaint yesterday was that
> the "whatever_test" was not documented).  Could you do
> that, Brian? I am still at a pypy sprint (grabbing my
> first coffee and such) etc

Sure, will do. It may be a day or so before I get a chance to do it.

Take care,
  -Brian


From Bryan.Weingarten at watchguard.com  Thu Jul 13 22:52:22 2006
From: Bryan.Weingarten at watchguard.com (Bryan Weingarten)
Date: Thu, 13 Jul 2006 13:52:22 -0700
Subject: [py-dev] license
Message-ID: <a5bcc619a08c08518f37c5df6040d46e47bee1b0@localhost>

I can't seem to find the license for py.lib (py.test) at the web site or
in the py-0.8.0-alpha2 package.  My company requires that we maintain a
reference to this before we can use it in our product.  So any pointers
to the license would be helpful. 

Thanks,

bryan


From jan at balster.info  Thu Jul 13 23:20:03 2006
From: jan at balster.info (Jan Balster)
Date: Thu, 13 Jul 2006 23:20:03 +0200
Subject: [py-dev] license
In-Reply-To: <a5bcc619a08c08518f37c5df6040d46e47bee1b0@localhost>
References: <a5bcc619a08c08518f37c5df6040d46e47bee1b0@localhost>
Message-ID: <44B6B903.4020702@balster.info>

Hey Bryan!

Nice to see you! Still no subversion hole in the firewall? ;)

You are finally using it your product? cool :)

py.lib is licensed under the MIT license.
If the license file is not in the tarball, you can find it in the subversion
repository:
http://codespeak.net/svn/py/dist/py/LICENSE

best,
  Jan

Bryan Weingarten wrote:
> I can't seem to find the license for py.lib (py.test) at the web site or
> in the py-0.8.0-alpha2 package.  My company requires that we maintain a
> reference to this before we can use it in our product.  So any pointers
> to the license would be helpful. 
> 
> Thanks,
> 
> bryan
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From Bryan.Weingarten at watchguard.com  Fri Jul 14 00:14:14 2006
From: Bryan.Weingarten at watchguard.com (Bryan Weingarten)
Date: Thu, 13 Jul 2006 15:14:14 -0700
Subject: [py-dev] license
Message-ID: <cf6da4c534e84c793baadcfd766e18784aa8baa1@localhost>

hi jan,

thanks for replying.  actually, we just added subversion (webDAV)
capability this week.  webDAV uses commands that are extensions to the
http protocol which was just added to the firewall proxy.  the code is
checked in, so it should be available on the engineering firewall
whenever they do the next major upgrade.   

py.test is working out really well for us.  I've made it the standard
python unittest framework here and it's working well for everyone,
nothing but compliments.  so thanks for a great product.  today I was
customizing our embedded version of python that we will eventually
deliver with our products, adding and deleting files and packages
including py.lib. so unless I remove py.lib for some reason (and my
company doesn't go out of business :), py.lib should eventually be
installed on 10's of thousands of computers.

I plan to attend pycon 2007, so I'll see you again if you make it.


bryan


-----Original Message-----
From: Jan Balster [mailto:jan at balster.info] 
Sent: Thursday, July 13, 2006 2:20 PM
To: Bryan Weingarten
Cc: py lib developers
Subject: Re: [py-dev] license

Hey Bryan!

Nice to see you! Still no subversion hole in the firewall? ;)

You are finally using it your product? cool :)

py.lib is licensed under the MIT license.
If the license file is not in the tarball, you can find it in the
subversion
repository:
http://codespeak.net/svn/py/dist/py/LICENSE

best,
  Jan

Bryan Weingarten wrote:
> I can't seem to find the license for py.lib (py.test) at the web site
or
> in the py-0.8.0-alpha2 package.  My company requires that we maintain
a
> reference to this before we can use it in our product.  So any
pointers
> to the license would be helpful. 
> 
> Thanks,
> 
> bryan
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From fijal at genesilico.pl  Fri Jul 14 12:01:52 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 14 Jul 2006 12:01:52 +0200
Subject: [py-dev] Import problems
Message-ID: <44B76B90.6000908@genesilico.pl>

  I want to make py.execnet import remotely. So what I perform:
- make new __import__ hook, so we can try local import or ask for 
sources from server (via some channel), sources are got by py.code.Source()

but...

  There are problems with importing py lib itself. For some modules it 
tells that there are builtin modules (py modules), because of import 
hooks. On the other hand copying py.lib is not what I want to achieve.
  Any clue?



From jan at balster.info  Fri Jul 14 12:39:05 2006
From: jan at balster.info (Jan Balster)
Date: Fri, 14 Jul 2006 12:39:05 +0200
Subject: [py-dev] Import problems
In-Reply-To: <44B76B90.6000908@genesilico.pl>
References: <44B76B90.6000908@genesilico.pl>
Message-ID: <44B77449.9010408@balster.info>

Hi Maciek,

about which python modules and pylib modules are you talking? Do you mean the
thread module? Can you provide some more informations?

A guess from my side:
These modules are included in the bootstrap code. Maybe the imports done in this
code are blocking your imports:

startup_modules = [
    'py.__.thread.io',
    'py.__.thread.pool',
    'py.__.execnet.inputoutput',
    'py.__.execnet.gateway',
    'py.__.execnet.message',
    'py.__.execnet.channel',
]


Maciek Fijalkowski wrote:
>   I want to make py.execnet import remotely. So what I perform:
> - make new __import__ hook, so we can try local import or ask for 
> sources from server (via some channel), sources are got by py.code.Source()
> 
> but...
> 
>   There are problems with importing py lib itself. For some modules it 
> tells that there are builtin modules (py modules), because of import 
> hooks. On the other hand copying py.lib is not what I want to achieve.
>   Any clue?
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From benno at jeamland.net  Sun Jul 23 15:39:46 2006
From: benno at jeamland.net (Benno Rice)
Date: Sun, 23 Jul 2006 23:39:46 +1000
Subject: [py-dev] Greenlet module appears to be rebuilt on every import
Message-ID: <495E4BBA-60DD-4CE9-BA8D-8B71F0FB713A@jeamland.net>

Hi,

I'm running into an odd problem trying to use greenlets on Mac OS X  
10.4.7 with Python 2.4 built from DarwinPorts and the py lib from  
subversion as of 23 July 2006.

Whenever I try to import greenlets I get the following:

Python 2.4.3 (#1, Apr 20 2006, 12:04:55)
[GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from py.magic import greenlet
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/initpkg.py", line 180, in __getattr__
     result = self.__package__._resolve(extpy)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/initpkg.py", line 68, in _resolve
     implmodule = self._loadimpl(fspath[:-3])
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/initpkg.py", line 98, in _loadimpl
     return __import__(modpath, None, None, ['__doc__'])
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/magic/greenlet.py", line 5, in ?
     greenlet = path.getpymodule().greenlet
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/path/local/local.py", line 404, in  
getpymodule
     mod = make_module_from_c(self)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/misc/buildcmodule.py", line 37, in  
make_module_from_c
     lib.remove()
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/path/local/posix.py", line 111, in remove
     self._callex(os.remove, self.strpath)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/path/common.py", line 227, in _callex
     raise cls, value
py.error.EACCES: [Permission denied]: remove('/opt/local/Library/ 
Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/ 
py/c-extension/greenlet/greenlet.so',)

I've checked this out and it looks like something in the import logic  
wants to compile the greenlet module every time I import it.  This  
leads to two questions:

1) Shouldn't the greenlet module get built when I run the build  
target of the setup.py script?
2) Isn't this a rather large bug in normal operation since the site- 
packages directory should be owned by root?

Is there a way to have the greenlet module be built once during the  
build phase of setup.py and then just used statically after that?

-- 
Benno Rice
benno at jeamland.net
http://jeamland.net/