Copier 6.0.0a9 supports Python 3.10, but its dependency `iteration_utilities>=0.11.0` does not
See original GitHub issueDescribe the problem
I have opened an issue over at MSeifert04/iteration_utilities#333 regarding the support of Python 3.10. I’m opening an issue here to track that as well, but of course feel free to close it if you deem it irrelevant to track upstream dependencies in this fashion. Would it be a good idea to implement an “install from wheels only” check in CI/CD to flag this issue automatically going forward?
Copier 6.0.0a9 supports Python 3.10, but its dependency iteration_utilities>=0.11.0
does not. Since there are no Python 3.10 wheels available on PyPi for iteration_utilities
, the user must build their own and hope that deepflatten
works properly (it probably works fine). This was previously masked by #605.
I have successfully installed Copier 6.0.0a9 in Python 3.10 on two Windows 10 machines that have the proper build tools. On the machine w/o proper build tools, however, installation fails. This configuration represents a more casual user use-case that might be worth considering.
To Reproduce
Attempt to install copier
for Python 3.10 without adequate build tools to compile its dependency iteration_utilities>=0.11.0
.
Logs
Fatal error from pip prevented installation. Full pip output in file:
C:\Users\Tiana\.local\pipx\logs\cmd_2022-03-14_18.56.40_pip_errors.log
pip failed to build package:
iteration_utilities
Some possibly relevant errors from pip install:
error: subprocess-exited-with-error
error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/
error: legacy-install-failure
Error installing copier from spec 'copier==6.0.0a9'.
Expected behavior
Wheels exist for upstream dependency so that Copier installs properly on Python 3.10.
Environment
- OS: Windows 10
- Copier version: 6.0.0a9
- Python version: 3.10
- Installation method: pipx+pypi
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top GitHub Comments
I do understand your rationale, especially on Linux as C++ toolchains are pretty much baked into any distribution. And hopefully
iteration_utilities
will officially have wheels on PyPi for Python 3.10 someday soon, and this issue will be moot.My concern is that once you officially release Copier 6.0.0 stable on PyPI, many Windows users will not be able to install Copier due to MSVC C++ toolchain not being installed by default. I empathize with the fact that this bug is not your responsibility, but the reality is that many Windows users of Python don’t dabble in C++ and hence won’t have the proper tools installed. I think Copier is a wonderful tool and I wouldn’t want Windows users to pass it up due to a pesky bug like this. For example, I hope to pass along my Copier templates to less tech-savvy Windows-using colleagues who are just getting into Python, and I would prefer not to scare them away by requiring jumping through C++ toolchain hoops.
This issue may need to be pinned for visibility when Copier 6.0.0 and above are the stable release on PyPI, as I think you will get more Windows users stumbling into the weirdness of the
UnicodeEncodeError
(see #605) error message not saying anything about needing to install MSVC. If worse comes to worst, anditeration_utilities
doesn’t end up supporting Python 3.10, is it feasible to vendor the usage ofdeepflatten
intocopier
, as it is the only function you’re using fromiteration_utilities
? I know this is the least palatable option, as you would be maintaining that C++ function yourself, which is not fun.Workarounds
For posterity, I will reiterate the various workarounds available for Windows users wishing to install Copier 6.0.0 and above once it’s stable:
copier
with Python 3.10, instead use Python 3.9 (e.g.py -3.9 -m pipx install copier
).iteration_utilities
may eventually have wheels for Python 3.10 on Windows.py -3.10 -m pipx install copier
should work.pipx
environment and inject this wheel into it, then install copier into that same environment. This workaround will expire at some point, as workflow run artifacts are not available indefinitely.Thanks for your understanding, I know it’s a lot of work supporting the quirks of various operating systems. I’ve got my own blindness towards certain Linux/MacOS quirks in the same way.
Okay, I will add to the FAQ in a PR sometime soon.