[TIP] pytest / pylib / tox release splitting plan

[holger krekel]

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