These are chat archives for symengine/symengine

12th
Oct 2015
Ondřej Čertík
@certik
Oct 12 2015 15:09
I am going to move sympy/symengine to symengine/symengine now.
Ondřej Čertík
@certik
Oct 12 2015 15:18
Ok, repository is moved: https://github.com/symengine/symengine and the old url redirects.
Ondřej Čertík
@certik
Oct 12 2015 15:25
I am testing travis + appveyor here: symengine/symengine#614
@isuruf looks like Travis works, but not appveyor. I am looking into it.
Isuru Fernando
@isuruf
Oct 12 2015 15:27
You can add the project. I see symengine/symengine in my account
Ondřej Čertík
@certik
Oct 12 2015 15:31
I think it works, I jut had to manually rename the github url in appveyor
Isuru Fernando
@isuruf
Oct 12 2015 15:42
symengine/symengine.py#2 is ready now
Sumith Kulal
@Sumith1896
Oct 12 2015 15:57
Cool
Isuru Fernando
@isuruf
Oct 12 2015 16:46

@certik, since we are separating the python wrappers, I think we should make SymEngineConfig.cmake more robust. How about something like this?

We install all our FindPKG modules. From SymEngineConfig.cmake we set GMP_INCLUDE_DIRS="absolute_path:relative_path" and then call find_package(GMP). Is this okay?

Ondřej Čertík
@certik
Oct 12 2015 16:47
What would be the advantage versus simply hardwiring the paths?
That the user can install gmp in a different location?
Isuru Fernando
@isuruf
Oct 12 2015 16:48
That user can download a binary of libsymengine, libgmp and compile python wrappers
Ondřej Čertík
@certik
Oct 12 2015 16:48
One thing that we can do is allow the user of symengine.py to specify where the gmp headers/libraries are, but use the fullpath given by symengine as a hint.
So if the gmp location didn't change, it will pick it up automatically, but if it changed, then the user needs to specify it explicitly.
Isuru Fernando
@isuruf
Oct 12 2015 16:51
That is certainly possible. We can implement this logic in SymEngineConfig.cmake and use setup.py install --define="GMP_DIR=/path"
Ondřej Čertík
@certik
Oct 12 2015 16:52
@isuruf how do other cmake project handle this issue? I.e. that one library installs using cmake, and then other projects want to use it, and perhaps reuse some of the cmake config?
Isuru Fernando
@isuruf
Oct 12 2015 16:53
they install FindPkg modules along with ProjectConfig.cmake
<prefix>/lib/cmake/symengine/FindGMP.cmake etc.
Ondřej Čertík
@certik
Oct 12 2015 16:55
Then we should do that.
Ondřej Čertík
@certik
Oct 12 2015 18:29
@isuruf let me know what needs to be done in the Python repo before we can yank the Python wrappers from symengine itself.
Isuru Fernando
@isuruf
Oct 12 2015 18:30
You only need to add this patch https://github.com/symengine/symengine/compare/master...isuruf:master
and then it's fine.
It still has the main repo as github.com/isuruf/symengine.py
Ondřej Čertík
@certik
Oct 12 2015 18:31
Can you send a PR?
We don't need to worry too much about breaking experience, since most of our users are developers so far. We just need to make sure we set things up for a long term development. I am confident that this split is the way to go.
Isuru Fernando
@isuruf
Oct 12 2015 18:34
I sent a PR
Of course, if someone can install symengine through conda, apt-get, then that's enough I guess
Ondřej Čertík
@certik
Oct 12 2015 18:36
@isuruf why don't we test the Python wrappers in the symengine.py repo only?
@isuruf another question is --- do we want to keep Shippable around?
Isuru Fernando
@isuruf
Oct 12 2015 18:38
I didn't change the tests because I didn't know what should be done about tests.
No python tests or one that is allowed to be a failure?
I don't think we'll need Shippable anymore.
Ondřej Čertík
@certik
Oct 12 2015 18:38
I think Shippable is not even run anymore.
Let's get rid of it then. We can always pretty easily use it again if needed.
I thought about the pros and cons. And I am thinking of actually only testing the C++ and C code in the symengine repo. This will force us to make sure that everything is covered by C++ and C tests, and also to think harder about the public API that we expose. For example I think we should have a set of headers that are the public API, and the rest of headers are for internal use only and those can change without problems. For public API, we should be more careful.
It will simplify the test suite a lot, since suddenly we don't care about Python, Ruby or Julia. Instead, we can use the freed test time to test some more of the C++ stuff, or perhaps more of our optional dependencies.
Then, in the symengine.py, we would test just Python, but very very thoroughly.
So the symengine.py will pull in a certain git commit of symengine and that will work. Then if we break the API by a mistake, let's say, then next time we update symengine.py, we notice that the PR to symengine.py (that updates the git commit of symengine) fails, so we either update the wrapper, or fix symengine first.
Ondřej Čertík
@certik
Oct 12 2015 18:43
Let me know what you think.
Isuru Fernando
@isuruf
Oct 12 2015 18:47
I agree. We have been doing lots of changes the public headers and we need a stable public API
Ondřej Čertík
@certik
Oct 12 2015 18:49
I expect that it will take us some time to figure out a nice API, but at least by designing what the public API is, we can track the changes (between releases) and document them (and how to update user code).
We should follow this: http://semver.org/