A start at a multi-version release pattern.

[ralphbean]

This commit moves everything that was in the kitchen/ source dir into a new
kitchen2/kitchen/ source dir. Eventually, we'll merge the py3port branch
into a kitchen3/kitchen/ source dir parallel to it.

I added both source folders to MANIFEST.in so when we create a tarball
with python setup.py sdist, both source directories will be
included -- kitchen2 and kitchen3.

When the user downloads and installs the package with pip install kitchen, it will download the tarball with both sources, unpack it, and
run the single setup.py. setup.py has new logic in it now that will detect
if the user is running python2 - if it is, then it will install kitchen
from the kitchen2/ directory. If they're running python3 it will install
kitchen from the kitchen3/ directory.

Note that, the imports for users do not change at all. For both python2
and python3, kitchen can still be accessed with

>>> import kitchen

/cc @abadger, @rkuska

[dtgay]

Looks good to me! 👍

[abadger]

Looks good. Remember to test python setup.py sdist after getting the python3 directory in there. I think the way you have it setup will work but sometimes distutils/setuptools do the unexpected.

+1

[ralphbean]

OK - the py3 bits are included now and both py2 and py3 sdist and test work locally on my machine in separate venvs.

However, travis is complaining for both sets here -> https://travis-ci.org/fedora-infra/kitchen/builds/40675442

The localization stuff is new to me. Anybody have any ideas about that?

[abadger]

Was this working before merging this to a branch? kitchen is working in jenkins (I'm not sure if we are testing both the standard py2 branch and the py3port branch there, though). These errors look like someone will have to dive deeply into the test cases and figure out what's wrong, perhaps correcting code. But since it's been working in jenkins I'm thinking it may be a configuration problem with how we're interacting with travis specifically rather than something wrong with kitchen's code.

Or it could be the swithing code -- might want to try adding travis to the main branch first and seeing if that works.

Also note, I'm not sure you caught this but the python2 and python3 tests are different. The py3port branch was written before python3 gained unicode literal strings like: u'test' . There were some other differences as well (for instance, python3 didn't need all of the py2compat libraries and the gettext API for python3 is superficially different than the python2 gettext API, surrogateescape may have also been a difference but I can't recall). To begin with, you'd want to import the test suites from the correct branches to run with the python2 or python3 code. Over time, the two could probably be merged together and certain tests skipped or an alternative version run on each of python2 and python3.

[ralphbean]

Or it could be the swithing code -- might want to try adding travis to the main branch first and seeing if that works.

My first bet is that the problem is here. Perhaps the locale/ stuff is out of reach for the "switched" tests.

the python2 and python3 tests are different

Yeah, I did catch this. :) Each of the kitchen2/ and kitchen3/ dir has their own tests/ dir now. The runtests.sh script from e051115 allows travis to find the right test set for the right python environment.

[ralphbean]

try adding travis to the main branch first and seeing if that works.

Interesting - master branch fails in travis as well -- https://travis-ci.org/fedora-infra/kitchen/jobs/40796519

I'll look a little more, but I might just chalk it up to a travis oddity. I'm not particularly invested in making things work there as opposed to jenkins or elsewhere.

[ralphbean]

Here jenkins is happy with both python2 and python3: http://jenkins.cloud.fedoraproject.org/job/kitchen/4/console

I'll remove the travis stuff and prepare a release.