Review/prepare release 0.17 #305
Conversation
|
@jf--- Can you please test/review this branch (compile on osx and check there's not error) @rainman110 I plan to release a new 0.17 version in a couple of days, will it be possible for you to update your conda repos ? |
|
@tpaviot great news. I will update them as soon it is released. Are there new build dependencies? |
|
@rainman110 The dependencies remain unchanged, compiling this new pythonocc should be straight forward. Thank you for your help |
|
Will this bundle SMESH with pythonOCC when installed using Conda or do I have to compile it separately? |
|
@rainman110 I see you're updating the dlr sc conda repository. Good, it allows me to run some tests. Do you also plan to add conda binaries for Windows 32/64 ? |
|
@tpaviot Yes, I am already on the windows builds. Unfortunately, I have problems with vtk. Somehow, the win32 vtk is not anymore in the anaconda repos, so I have to build it on my own or look for another repository. I also have to warn you, that we applied a patch to OCE to enable C2 continous coons patches. This was developed by the OCCT guys for the DLR. The problem is, that is modifies 3 header files and you will probably get problems when creating the swig wrappers. My solution will be, to provide some patches as well for pythonocc. I don't know how you like to handle this during your CI builds. Maybe this is the point, where we / you should switch over to a oce/pythonocc anaconda repo. |
|
@rainman110 Yes I noticed issues with Linux and OSX builds on python27. I modified the wrapper to handle that. I prefer rely on your patched oce rather than have to feed my own conda repos. |
|
@rainman110 It seems this patch is enough f8a90c6 to comply with your patched oce-0.17.2 |
|
@tpaviot This looks good. You can have a look to our patches by yourself. Just look for the header files: We also extended an enum: https://github.com/DLR-SC/tigl-conda/blob/master/oce-0.17/dlr-feature-coons_c2.patch#L65 I don't know if that also has to be adapated on the swig wrappers. |
|
@rainman110 I can't add your specific enum to the wrapper otherwiee it will break compatibility with official oce-0.17.2 release. |
|
@tpaviot No problem. If it still compiles, everything is good 😀 Just that we talk about the same thing: You are also applying these pythonocc patches only in conda right? |
|
@tpaviot Oh, I just saw, that you implemented the patch in a separate branch. I would rather make this a conda specific patch and add this to the conda recipe. Your pythoocc source should still compile with your unpatched oce right? |
|
@rainman110 This branch is a test for the patch. It won't be merged, indeed a patch directly in the conda receipe is much better. Tell me when it's done, I will trigger a new build on travis. |
|
@tpaviot I uploaded the binaries now for linux-64, osx (64) and win 32. win64 is yet to come, but i will not manage to build them today. the patch is already done, I won't change anything in that respect. |
|
@rainman110 Also swig should be upgraded to 3.0.10 version (this version fixes a bug with operator overloading for gp_Vec and gp_Pnt) |
|
@tpaviot I think the 3.0.9 already fixed this bug, which I have in my repos (Except for os x at the moment) You mean this issue, right: #257 (comment) |
|
Oh man. We have a glibc error: https://travis-ci.org/tpaviot/pythonocc-core/jobs/161005538#L3158 This means, that my linux build machine is too new. I tought it would suffice, to use the gcc compiler shipped with conda. |
|
I am wondering, why it fails only for the python 2.7 linux build and not for the other linux builds. The oce linux binaries are all the same and thus we should get the libc error always. Very strange! Update: Okay, I got it. The other builds still used oce 0.17.1. |
|
Okay... it's just about the |
|
@rainman110 ok, good. Tell me when you're done with pythonocc patches so that I can test with travis. |
|
@rainman110 You're right, swig 3.0.9 fixes the issue (see #278). |
|
@tpaviot I added a patch to my oce builds to provide backwards compatibilty of glibc: I am now compiling OCE 0.17.2 and uploading it to conda ASAP. |
|
@tpaviot The new OCE 0.17.2 linux build is online. Please retrigger your travis builds! |
|
@rainman110 master rebuilds on travis https://travis-ci.org/tpaviot/pythonocc-core/builds/160402826 |
|
@tpaviot Your travis downloads the wrong oce version. I am not sure, why this happens: Update: my fault... I forgot to upload the freeimageplus package. Retry now again. Sorry for confusion. |
|
@tpaviot The new conda build (v2) seems to be buggy. Please use version 1.20 instead. The folks at conda-forge also pin the conda-build version to 1.20: |
ci/conda/meta.yaml
Outdated
| - patch [win] | ||
| - python | ||
| - oce 0.17.* | ||
| - oce 0.17.2 |
There was a problem hiding this comment.
this is a wrong syntax. this will give you nasty errors ;) I was struggeling with it right now
Use oce ==0.17.2 instead
ci/conda/meta.yaml
Outdated
| - wxpython [py27] | ||
| - pyside [py27] | ||
| - oce 0.17.* | ||
| - oce 0.17.2 |
|
There is the next problem... I compiled OCE with VTK support. VTK is offered by Anaconda itself, but only for python 2.7. Therefore, now all python 3 packages fail to build, as there are no VTK packages for python 3. There are two options:
@tpaviot What would you suggest? Remember, VTK is pretty large, right? |
|
@rainman110 VTK support is not necessary so far. I don't use it, noone ever requested for VTK support in pythonocc or oce. I suggest we drop VTK support, it's much more important that we have both py2 and py3 support on conda |
|
@tpaviot Okay... then I remove the VTK requirement for running oce. I will trigger a rebuild now for linux and later for osx. On windows, I already made the VTK packages. The question is, if it should be a install requirement or not. If yes, a pythonocc installation will be pretty large (including the vtk stuff) |
|
@rainman110 A solution that prevents a VTK installation is better than any other |
|
@tpaviot Both linux and osx builds are updated, this time without vtk. Unfortunately, travis timeouts in my account after 46 minutes just before the tests: Technically, the builds should work fine. |
tpaviot
force-pushed
the
review/prepare-release-0.17
branch
2 times, most recently
from
6d845c5 to
5c33c33
Compare
|
@rainman110 Build is going fine, see https://travis-ci.org/tpaviot/pythonocc-core/builds/161543188. On travis, forcing oce to 0.17.2 and conda-build to 1.20 is ok. I also added the GeomFill patch necessary to comply with dlr-sc patched oce. However, conda build on appveyor is still failing https://ci.appveyor.com/project/tpaviot/pythonocc-core/build/pythonocc-core-0.17.407. This morning, a new issue related to a conflict with patch version ! Generally speaking, conda/travis and/or conda/appveyor are not robust at all. Impossible to predict whether or not tomorrow the build will still be ok :-( Such a nightmare and waste of time getting the things work ! |
|
@rainman110 Appveyor debugging drives me crazy. I give up for now. |
|
@tpaviot Yes, I also have the impression, that conda is really unreliable these days and it's getting worse with each release. Did you try fixing also conda-build at 1.20 on appveyor? It's a shame since conda is a great idea, but it's implementation is nuts. If you have a syntax error in the meta.yml, you don't get any (reasonable) feedback but just an exception and a call stack. |
|
@rainman110 Yes, I tried on appveyor all the travis tricks, but unfortunately it does not work. Nevertheless, I merge this PR, tag pythonocc-0.17 so that you can build the conda binaries. |
|
@tpaviot I have the impression that I has something to do with our oce 0.17.2 windows packages. If I let it build against OCE 0.16, we don't have these strange conda issues. I will compile oce now again on windows without vtk support and hope, that it fixes the problems. |
|
@rainman110 I relaunched an appveyor build just now. It seems that is goes better see https://ci.appveyor.com/project/tpaviot/pythonocc-core, at least the code is compiling. |
|
@rainman110 It's getting better on the appveyor side. Compilation is ok on both py27 and py35 under 32 bit. However it still fails on Win64, due to a package conflict. I will comment out 64 bit build, just to have the green flags, we'll see later how to fix that. |
|
@tpaviot The 64 bits should work now also. I uploaded yesterday evening the new packages. Try again building now! (It always takes some time to build the packages, as I have to compile 4 windows packages and each takes about one hour) |
|
@tpaviot By the way. There is miniconda preinstalled on appveyor: The guys at conda-forge are using it as follows: Thus, you can save a little time by skipping the download phase. I already tried it out and it seems to work nicely. Also, I didn't need to include the CMD_IN_ENV hack. I just call conda as usual. Here's my temporary recipe, which worked fine: |
|
@rainman110 I launched a new compilation stage on appveyor, hopefully the 64 bit package will build as well. Thanks for the hint related to the preinstalled miniconda on appveyor. So far, looking for green flags is my priority, I will take this into account after 0.17 is released. Indeed, I don't want to refactor the appveyor YAML right now, it's really too much time getting something achieved. |
|
@rainman110 Yeepee, everything's green ! |
|
@rainman110 FYI I tagged pythonocc-0.17 |
|
@tpaviot great! Then I start building the releases! |
|
@tpaviot / @rainman110 , would it be OK to announce the next release after some PR wrt new features specifically for this release?
You'll have PR's on Sunday for these |
|
@jf--- pythonocc-0.17 is tagged, @rainman110 is building binaries for conda, ready to be announced. We already have waited a long time, I suggest you open PR for your new features, we will take our time to review, and we will release them in a 0.17.1 version, ok ? |
|
@tpaviot, Sure np! |
No description provided.