I have been trying to troubleshoot a unicodedecode error that I get: https://ci.appveyor.com/project/kavvkon/gams-api/build/1.0.8
For this reason I created a new branch and simplified the setup.py. However it seems that a previous version of setup.py is used.
Is it using some kind of cache? Any ideas on the above unicodedecode error? I wasn't able to reproduce locally. Thanks for the nice work
I think I see the problem. Correct me if I'm wrong but I assume you have already uploaded a wheel to PyPI? So when you run the build for the first Python version, you get
Executing: pip wheel gdxcc -w c:\users\appveyor\appdata\local\temp\1\cibuildwheelgp0rqv\built_wheel --no-deps
Collecting gdxcc
Downloading gdxcc-7.post2492.tar.gz (72kB)
Building wheels for collected packages: gdxcc
Running setup.py bdist_wheel for gdxcc: started
Running setup.py bdist_wheel for gdxcc: finished with status 'done'
I.e., instead of interpreting the gdxcc as subfolder, it's interpreted as a PyPI package and the source build is downloaded. That's why Using cached gdxcc-7.post2492.tar.gz pops up for the next Python version: that's not a cibuildwheel or AppVeyor cache, that's just pip having downloaded that before.
Quick fix to test your separate branch: use a different version number and don't upload it automatically to the PyPI!
Meanwhile I'll have a quick look to see if I can fix the call to pip wheel in cibuildwheel ...
I've just submitted a PR, #51. If tests run fine (they seem to be going well), I suggest you'd try to use that in your script (i.e., pip install cibuildwheel from https://github.com/YannickJadoul/cibuildwheel/archive/single-subdir-project-fix.zip)
Thanks for the fast reply. Indeed it was downloading it, even after the version bump. I fixed it by explicitly calling the directory as follows:
- cibuildwheel ./gdxcc --output-dir wheelhouse
I have still the unicode error though and I cannot track it. Locally it builds fine. Do you think it is related with this package?
Ha, that's of course an even easier solution, just prepending './' :-D
I don't think the unicode error has something to do with cibuildwheel, but I was just looking at the error, and it seems it's related to MANIFEST.in. So I downloaded that file, and ... there is apparently an invisible 0x90 character in there (see screenshot) that distutils is complaining about: UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 in position 60: character maps to <undefined>?

Well, that was a bit embarrassing :) Seems to work fine now, many thanks for the help and this nice package!
Don't worry. Rather, thanks for finding this issue in cibuildwheel with the subfolder/package!
Top work debugging this @YannickJadoul! the PR's merged now, so this should be fixed.
Most helpful comment
I think I see the problem. Correct me if I'm wrong but I assume you have already uploaded a wheel to PyPI? So when you run the build for the first Python version, you get
I.e., instead of interpreting the
gdxccas subfolder, it's interpreted as a PyPI package and the source build is downloaded. That's whyUsing cached gdxcc-7.post2492.tar.gzpops up for the next Python version: that's not acibuildwheelor AppVeyor cache, that's justpiphaving downloaded that before.Quick fix to test your separate branch: use a different version number and don't upload it automatically to the PyPI!
Meanwhile I'll have a quick look to see if I can fix the call to
pip wheelincibuildwheel...