New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A start at a multi-version release pattern. #4
Conversation
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 ```python >>> import kitchen ``` This commit doesn't actually include any of the python3 bits, but it stubs out one approach we could use which I'm submitting for feedback and potential usage.
Looks good to me! 👍 |
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 |
… to make things easier.
OK - the py3 bits are included now and both py2 and py3 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? |
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. |
My first bet is that the problem is here. Perhaps the
Yeah, I did catch this. :) Each of the |
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. |
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. |
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 tarballwith
python setup.py sdist
, both source directories will beincluded -- 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, andrun 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
/cc @abadger, @rkuska