Support Python3 #41
Support Python3 #41
Conversation
I removed the explicit pkgs argument which meant the nixpkgs version CI tried to pin was ignored.
exarkun
force-pushed
the
support-python3
branch
from
dabeb75
to
aaddeac
Compare
On manylinux1, source checkout fails with "no kex alg" talking to GitHub. There's probably no reason to fight this battle.
maybe some images don't need it
.circleci/config.yml
Outdated
|
|
||
| - run: | ||
| name: "Build Wheel" | ||
| command: | | ||
| python setup.py bdist_wheel | ||
| << parameters.python >> -m pip wheel . |
There was a problem hiding this comment.
I'd suggest using python -m build (which uses build) or at least passing --no-deps. The current command builds (or fetches) wheels for all dependencies of the specified packages as well.
It looks like build puts the files in dist/, instead of the current directory.
There was a problem hiding this comment.
Hm. It looks like python -m build has a problem with the way the package is set up:
* Building wheel from sdist
* Creating venv isolated environment...
* Installing packages in isolated environment... (setuptools >= 40.8.0, wheel)
* Getting dependencies for wheel...
* Installing packages in isolated environment... (milksnake, setuptools_scm, wheel)
* Building wheel...
running bdist_wheel
running build
running build_py
creating build/lib
creating build/lib/challenge_bypass_ristretto
copying challenge_bypass_ristretto/__init__.py -> build/lib/challenge_bypass_ristretto
creating build/lib/challenge_bypass_ristretto/tests
copying challenge_bypass_ristretto/tests/__init__.py -> build/lib/challenge_bypass_ristretto/tests
copying challenge_bypass_ristretto/tests/test_privacypass.py -> build/lib/challenge_bypass_ristretto/tests
error: [Errno 2] No such file or directory: './challenge-bypass-ristretto-ffi'
ERROR Backend subproccess exited when trying to invoke build_wheel
If I take the progress indicator "Building wheel from sdist" at face value then I suppose the problem is that challenge-bypass-ristretto does not get included in our sdist so isn't available when this stage is reached.
Maybe addressing this and switching to python -m build would be a reasonable follow-up? Since it appears to be using bdist_wheel under the hood, just like pip wheel does, perhaps the wheels themselves are the same either way and python -m build is only preferable for project maintenance reasons? (In which case a follow-up fix seems fine)
Adding --no-deps seems trouble-free though so that much I can do now.
There was a problem hiding this comment.
I went to file a ticket for using python -m build and I realized I couldn't quite articulate the reason for preferring it. https://pypi.org/project/build/ says it is "a .. package builder" but doesn't try to claim to be the definitive package builder or anything like that. I'm not sure what the pros and cons of it vs pip wheel are. Do you feel like filing this ticket?
There was a problem hiding this comment.
There are a couple of things:
- partly it is that other tools are not the right choice:
- directly invoking
setup.pyis deprecated (see for example this comment and this section of setuptools documentation) pip wheelis intended to get wheels of all dependencies (possibly fetching them from pypi, or building them from sdists)
- directly invoking
- as for why build, it is the suggestion in setuptools' quickstart and by pep517's readme (the pep517 package is the implementation of the new API for building packages which is used by pip).
If I take the progress indicator "Building wheel from sdist" at face value then I suppose the problem is that challenge-bypass-ristretto does not get included in our sdist so isn't available when this stage is reached.
Yeah, it seems that (by default), build builds a sdist, and then builds a wheel from that. That suggests that the sdist that is produced can't actually be installed, which would be a reasonable thing to fix. You can pass -w to build, to get it to just build a wheel directly from source, which works.
| <<: *TESTS | ||
| environment: | ||
| NIXPKGS_REV: "20.09" | ||
| NIXPKGS_REV: "21.05" |
There was a problem hiding this comment.
I guess these are tags of the initial release of that branch, which is probably fine for running tests.
... and also stop testing Python 2 support
I also ended up mixing a lot of CircleCI configuration changes in here to do a better job of building wheels. It's possible this wasn't strictly necessary but it doesn't end up making the PR diff that big so I guess I'm planning to leave it here (the history is, of course, the usual mess of "does it work now?" that you see with most cloud service configuration reconfigurations...).