Hi all, here are some py.test/pylib/tox split release related stories i have been thinking about. Idea is to allow all kinds of installation / upgrade situations to succeed. My goal is to have "tox" only pull in the new small and mean "pylib" and not the whole pytest package. Another is to have a small mostly self-contained "pytest" package. And a third to seperate out the helper tools into a "pycmd" package.
Anyone who is interested in release management might want to read this, and maybe help me see the light or be inspired ... all others can just hope i get this right and don't mess up :) consider this situation: pip install py # you currently get sumo py==1.3.4, for using py.test pip install pylib # will be pylib==2.0.0 this would lead to "import py" coming from py==1.3.4 because the distribution 'py' "owns py" and came first. You'd also see funny tracebacks when invoking py.test. BAD. My planned fix is to provide a py==1.4.0 which has _no_ packages and have pylib depend on the exact "py==1.4.0" version. Then pip install pylib will lead to "import py" coming from pylib-2.0.0 because the py==1.4.0 is an upgrade to 1.3.4, thus removes its "py", package, no interference. Good. Now consider a tox user, typing:: pip install tox # let's assume this is 0.8 tox has a requirement of "py" and if this drags py==1.4.0 - BUMM! the tox installs breaks, because when it "import py" nothing is there. My planned fix is to provide *another* release "py==1.4.1" which will depend on pylib-2.0 and pytest-2.0 (and pycmd-1.0) so that people blindly installing tox like above will be happy and people doing pip install -U py and expecting to get py.test (because they are reading an old README or blog post) will also be happy and use the newest version of pytest/pylib. Finally, somebody starting a fresh installation with pip install pytest will just drag in pylib-2.0, which drags in py==1.4.0 which requires pylib-2.0 ... SIMPLE, good. You might wonder why i care so much and don't simply tell people "make sure you uninstall py first" or something like this. Reason: many people are using the above packages in Continous Integration situations and going to all kinds of masters, slaves and Job configurations to ensure removal of packages and such is not fun. And not everybody reads release messages anyway ... or understands what is installed in their environments - judging from myself :) best, holger _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev