On 07 septembre 18:41, Dan Stromberg wrote: > On Mon, Sep 6, 2010 at 10:59 PM, Sylvain Thénault < > > On 06 septembre 11:59, Dan Stromberg wrote: > > > On Mon, Sep 6, 2010 at 1:59 AM, Sylvain Thénault < > > > 1) Make the hierarchy in common's source directory mirror more closely > > what > > > goes into site-packages, in particular, making the automatically-created > > > __init__.py at the top no longer be automatically created. > > > 2) Introduce top-level 2.x and 3.x directories, where the 2.x directory > > has > > > the official sources (for now), and 3.x is automatically derived at > > > "setup.py install" time from 2.x using sa2to3. > > > > I'm not sure to understand the pb you're trying to solve here. > > Actually, there are two problems I'm hoping to solve with this. > > One is to have a directory that contains an exact mirror of what will go > into site-packages, to facilitate testing. That way, you can set PYTHONPATH > and your tests are comparing apples to apples.
We do that by cloning logilab.common into a logilab directory with a manually created __init__.py. This ends up to be much easy to use when you checkout other logilab'subpackages such as astng, constraint and so one. So I'm not very keen on changing this. > The other is... To me it seems the best way of getting 3.x sources from 2.x > is with sa2to3. But I believe sa2to3 is going to want to have two distinct > files for each module, one for 2.x, and one for 3.x. The clearest way of > distinguishing between these is to have two distinct but closely related > hierarchies: One authoritative (2.x), and the other 100% automatically > generated from the other (3.x). As I saw it, if we reach a purely generated 3.x sources, they don't have to be stored in the mercurial repository. It's only a matter of generating another tarball at release time. If you want 3.x sources from mercurial 2.x, you should simply have to generate them somewhere in your py3k PYTHONPATH. > Please note that eventually the relationship could conceivably be reversed > with 3to2. ok. > > > > When is the new unit testing code to arrive? I'd like to look it over > > > > soon > > > > > > > > it's just a matter of time to 1. switch existing test to unittest2, > > then to > > > > 2. > > > > ensure we can do what we use to do with pytest using discover (and > > > > eventually > > > > contribute missing feature). Regarding py3k port, #1 is enough so that > > we > > > > can > > > > just igore lgc.testlib and lgc.pytest modules. > > > > > > It seems likely that if the unittest2 code isn't merged first, > > substantial > > > merge conflicts will result. > > > > There is no merge to do, simply stop using logilab.common(lgc).testlib in > > tests. > > You are saying that the difference is solely in how the tests are invoked > from the command line? Unfortunatly not. logilab.common provides two testing modules: testlib and pytest. Our unittests are written using testlib (which extends the old unittest module with a lot of things like setup/teardown module, test skipping, etc...). As those features are now in unittest2, we don't want anymore to use this. So this is the first thing to do: use unittest2 instead of testlib. Hopefully that shouldn't be a big deal but it's still has to be done. Then, we used to run tests using pytest, which is a tests discover tool. Because of pytest tricks, we can't use it with tests written using unittest2. I also suppose we can't use discover on tests written using testlib (but I've not checked that yet). So one test will be written using unittest2, we'll simply have to use unittest2 discover tool instead of pytest to launch tests (and ensure it provides the same functionnalities we liked in pytest, but that's another topic). I've no time this week to work on this, but I'll try to find some next week. Regards, -- Sylvain Thénault LOGILAB, Paris (France) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org _______________________________________________ Python-Projects mailing list Python-Projects@lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-projects
