Skip to content
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

Merged
merged 5 commits into from Oct 22, 2014
Merged

Conversation

rkuska
Copy link

@rkuska rkuska commented Oct 10, 2014

What I have found and fixed.

@ralphbean
Copy link
Contributor

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, kitchen3? We could maintain two codebases and hopefully someday port everything off of the old py2-only kitchen.

@ralphbean
Copy link
Contributor

@abadger just pointed me at this, which might be of interest http://python-future.org/overview.html

@abadger
Copy link
Contributor

abadger commented Oct 13, 2014

@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.

@ralphbean
Copy link
Contributor

this is a merge to the py3port branch of kitchen

I missed that. Thanks!

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

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 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 didn't quite realize we could do that (two tarballs, one pypi entry). That's worth investigating.

@ralphbean
Copy link
Contributor

Thanks @rkuska for the patches, and sorry for the delay in getting around to merging.

ralphbean added a commit that referenced this pull request Oct 22, 2014
Necessary changes for py3port
@ralphbean ralphbean merged commit 8de6ba4 into fedora-infra:py3port Oct 22, 2014
@rkuska
Copy link
Author

rkuska commented Oct 22, 2014

Thanks @ralphbean for the merge! (and sorry for the late respond) :-)

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 didn't quite realize we could do that (two tarballs, one pypi entry). That's worth investigating.

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).

@rkuska
Copy link
Author

rkuska commented Oct 22, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants