This repository has been archived by the owner on Oct 5, 2020. It is now read-only.
Only include taskcluster.async on Python 3 #82
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jhford
suggested changes
Aug 8, 2017
There was a problem hiding this comment.
I like the objective here, but I don't think we can safely merge this commit. The problem is that the runtime which builds the source tarball has control over whether or not taskcluster.async is included in the package that needs to be runtime version agnostic.
This means that if you build sdist on 2.7 you don't get async but if you build on 3.5+ you do get it. This would result in a 3.5 built source distribution installed into a 2.7 runtime environment having a non-functioning async module installed and a 2.7 built source distribution installed into a 3.5 runtime environment would be missing the async module.
Because of the missing async module, we'd have to limit our building of the source distribution to python3.5+, which would result in continuing to package taskcluster.async for python2.7 anyway, defeating this commit's intention.
As well, the packaging of taskcluster.async doesn't cause python2.7 to generate an invalid source distribution. We also get an exception throw in 2.7 when trying to import taskcluster.async.
It always amazes me that python packaging doesn't have facilities for marking packages/files as being specific to python3 vs python2, since that was a breaking change and all.
Maybe there's a way to black list that module when building the py2 or py3 specific wheels?
Since it doesn't work on Python 2, so might as well be excluded there from the wheel and/or files installed from the sdist.
When generating an sdist, the build step that would invoke To confirm this: $ make devel
...
$ ./.tox/py36/bin/python setup.py sdist
running sdist
...
$ mv dist/taskcluster-1.3.4.tar.gz dist/py36.tar.gz
$ ./.tox/py27/bin/python setup.py sdist
running sdist
...
$ mv dist/taskcluster-1.3.4.tar.gz dist/py27.tar.gz
$ diff -U 0 <( tar -tf dist/py27.tar.gz | sort ) <( tar -tf dist/py36.tar.gz | sort )
$
There is - this PR :-) |
|
It looks to me like setup.py is being executed as the entry point into the packaging framework when building the sdist package, and that it is giving differing results when executed by 2.7 and 3.6. Is there something I'm overlooking here? Python 2.7 sdist creation Python 2.7 sdist output listing Python 3.6 sdist creation Python 3.6 sdist listing Git metadata |
|
I think what would be needed is to figure out of the |
|
Eugh it appears my results were due to yet another over-caching bug with setuptools/... A solution could be implemented using |
Possibly this one: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since it doesn't work on Python 2, so might as well be excluded there from the wheel and/or files installed from the sdist.