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
Necessary changes for py3port #3
Conversation
Good stuff. Thanks @rkuska! These kinds of changes are however not suitable for a single codebase that supports py2 and py3. If we were to merge these into the mainline branch, the docs would no longer be true for py2 usage. IIRC, the importlib stuff only works in py3 (there may be a third-party backport lib on pypi..). Anyways, that's all fine. How would you feel about forking this off into a separate repo, project, package called, say, |
@abadger just pointed me at this, which might be of interest http://python-future.org/overview.html |
@ralphbean Note: this is a merge to the py3port branch of kitchen. That branch is, at least for now, the python3 compatible work. Not sure what you want to do for the future -- whether to fork it off or work on a single codebase. I was keeping mainline and the py3port branch in sync with each other but I'm not sure if a few extra commits crept into mainline when we moved over from bzr. Also not sure what to do with the pypi project if we release a separate codebase for python3. I think pypi will allow us to host both tarballs at the same time. (Configure both in the pypi idea of a release, to do that, I believe). But I'm not sure if that's the way to go or if having a separate name on pypi is better. |
I missed that. Thanks!
Keeping them in the same repo, but as 'permanently' separate branches will work. I don't have experience with it, but I bet it will be less overhead in the end.
I didn't quite realize we could do that (two tarballs, one pypi entry). That's worth investigating. |
Thanks @rkuska for the patches, and sorry for the delay in getting around to merging. |
Necessary changes for py3port
Thanks @ralphbean for the merge! (and sorry for the late respond) :-)
I think that this is (theoretically) possible only in the way @abadger mentioned (if I understand correctly), i.e. to have kitchen-1.1.1 with metadata set to Python2 only and kitchen-1.1.2 with metadata set to Python3 only. (IMO) This will lead to problems with versioning/releasing and I would consider this as a hack. I would vote for separate package on pypi - kitchen3 or python3-kitchen even though it may create requirements mass for pypi packages (I hope that users of kitchen are fedora users mostly) but it will keep same version number for both releases so users can be sure that both packages provide same level of features. This is for today. For the future I would aim for codebase merge, but right now it's important to get a python3-kitchen into rawhide (fc22) so we can test out (its) dependencies (again IMO). |
Additional idea to have one pypi entry for both python2 and python3. It is maybe possible to use wheel binary, wheel binaries are tied to python-major.X versions. But I guess you still have to upload source to pypi. |
What I have found and fixed.