creating wrappers with python 3.7 #259
Comments
|
I can reproduce this error on my setup. It seems it is no longer possible to compile wrappers with recent python versions using a legacy pyplusplus 1.8.5. This probably means a long term solution is needed. In the short term can you think of a quick fix @chryswoods or @lohedges ? Compile wrappers on an old OS, and commit changes ? |
|
I also have the same issue with Python 3.7 on Linux. Just trying to see if I can get things working. |
|
I hadn't noticed before since I hadn't needed to regenerate the any wrappers since the latest miniconda update (which took us to Python 3.7). |
|
On Linux I just reinstalled $HOME/sire.app/bin/pip install pyplusplus --no-cache-dir
Collecting pyplusplus
Downloading https://files.pythonhosted.org/packages/e3/d6/6394a732d364d726fc4dfc9fa1832913f07aa2873f32c65298032e92bdb0/pyplusplus-1.8.1.tar.gz (164kB)
100% |████████████████████████████████| 174kB 4.6MB/s
Requirement already satisfied: pygccxml in /home/lester/sire.app/lib/python3.7/site-packages (from pyplusplus) (1.8.5)
Installing collected packages: pyplusplus
Running setup.py install for pyplusplus ... done
Successfully installed pyplusplus-1.8.1 |
|
Actually, version 1.8.1 is the latest version on pip. |
|
When I do that I now get a gccxml error. Did you also reinstall this software or change settings? |
|
Is it possible to try using CastXML rather than GCC-XML. This has succeeded GCC-XML. I have both installed on my Linux machine but it looks like CastXML takes precedence. |
|
Unfortunately this triggers another error on my setup There are also a bunch of warnings that may or may not be problematic Note that castxml did take precedence automatically as in your setup |
|
That's strange. If you look at the create_wrappers.py script you'll see that the castxml --version
castxml version 0.1-gae93121-dirty
CastXML project maintained and supported by Kitware (kitware.com).
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: |
|
Bit frustrating ! It sounds like we need to revisit how to support wrappers compilation In the meantime could you please commit the recompiled wrappers to devel if they work correctly? I will merge the changes in @SofiaBariami 's branches so she can keep progressing with her project. |
|
Agreed, it's rather frustrating. One suggestion from @chryswoods is to create a docker environment in which to build the wrappers. I'll look into this. I'm a bit confused by you question regarding the wrappers on devel. Do you mean to compile the wrappers on @SofiaBariami's feature branch where the API has changed? (Basically recompile the |
|
Sorry yes it makes more sense to update the wrappers on her branch
…Sent from my iPhone
On 19 Mar 2019, at 12:35, Lester Hedges <notifications@github.com<mailto:notifications@github.com>> wrote:
Agreed, it's rather frustrating. One suggestion from @chryswoods<https://github.com/chryswoods> is to create a docker environment in which to build the wrappers. I'll look into this.
I'm a bit confused by you question regarding the wrappers on devel. Do you mean to compile the wrappers on @SofiaBariami<https://github.com/SofiaBariami>'s feature branch where the API has changed? (Basically recompile the Sire.Move wrappers there and upload the modified files.) The wrappers on devel work fine for me without needing any recompilation. Is this not the case for you?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#259 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ALLd5CKrKZVPjWcU__zh8dTvtrxyBET1ks5vYNmAgaJpZM4b0njo>.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
|
|
Okay, the updated wrapper files have been pushed to the |
|
I'm close to having a working Docker container for building wrappers. In building it I've come across the same error that @jmichel80 saw above, i.e. As mentioned previously, I've compiled the updated wrappers and they appear to work as before. If @chryswoods could confirm that this is a valid solution, then I'll update create_wrappers.py and push the Docker container. (You should also be able to build them locally too using CastXML.) |
|
Yes, this is a good solution. Thanks for getting this working in docker :-) |
|
Okay, I updated the code, which didn't change a single wrapper file and now the Azure build fails with an error in |
|
And of course, it builds completely fine locally in a clean Sire Miniconda. Seriously, how is one meant to debug stuff like this! |
|
Even more ridiculous: I've run the sire-devel-latest Dockerfile locally and it builds fine! How is this even possible? Unless some of the Conda build dependencies have updated in the last hour (which they haven't) I really can't see how this could happen. So much for reproducible builds. I guess I'll have to push a new commit to Sire devel to see what happens. (Triggering a rebuild of the same commit failed.) |
|
So, pushing a completely unrelated change to a README file appears to have fixed things. I reiterate that none of the wrappers have changed in any of the commits, nor the source code. If anyone has any explanation for why this occurred then I'm all ears. Note that it wasn't a random failure, since both the Linux and macOS builds failed, and they failed consistently when a re-build was triggered. The only thing that I can think of is that, since the order in which the wrappers is built is variable, I hit some random situation where the wrappers were built out of order. (Perhaps due to the parallel nature of of the build with CMake.) So far this week I've had a Dockerfile not generating a consistent image on two machines and two Conda versions (one version apart) generating completely different package plans for the same install. (One of which was broken.) Basically, the concept of reproducible builds and reproducible environments is dead. Perhaps we should just go back to shipping binaries. At least we can test those ourselves and it's our fault when they're broken! |
|
I now have a working Docker container, based on This will place you inside to fetch the latest updates and switch to your feature branch. Then you can build wrappers as follows: You can then commit your changes and push the updates. (I'll think of a way of easily setting GitHub user account credentials within the container.) Alternatively, you could copy the updated files out of the Docker container and commit them in your local repository. |
@SofiaBariami and I had a go at creating wrappers and came across this error:
After some minimal googling I would assume that there is an issue with the regular expression matching from pyplusplus that does not work with python 3.7 (or 3.6). Not 100% sure though and would love some other input.
My idea to test this was trying to use python 3.5 and see if the wrappers could be created, but a simple downgrade of python with conda wasn't possible and I didn't want to then dive down too many rabbit holes.
The text was updated successfully, but these errors were encountered: