Build ta-lib from source if the library is not found

[mckelvin]

• Combine all extensitons (namely common, abstract, func, stream) into one extension (c_ta_lib) Why? SEE: Trying to build ta-lib from source if the library is not found #110 (comment)
• git subtree add --prefix vendor/ta-lib https://github.com/TA-Lib/ta-lib.git v0.4.0 --squash (https://github.com/TA-Lib/ta-lib/releases/tag/v0.4.0)
• Update setup.py to make it fallback to build-from-source
• Move the testing related code to tests and refactor for py.test (a better alternative to nose)
• Support python setup.py test
• Support Travis-CI

Since there're a few changes of generated files. Please review commit by commit and ignore the commits related to generate code. You can later check the generated cython c files by rerun using Cython 0.24.1 and verify the vendor/ta-lib with https://github.com/TA-Lib/[email protected] or http://prdownloads.sourceforge.net/ta-lib/ta-lib-0.4.0-src.tar.gz and verify using diff -rN dir1 dir2.

SEE ALSO:

• Trying to build ta-lib from source if the library is not found #110

[mckelvin]

@mrjbq7 You may need to enable the travis service for this repository.

And you can also check the CI status of this PR in https://travis-ci.org/mckelvin/python-ta-lib/branches .

[femtotrader]

Nice! it could help to bring CI to my Julia wrapper https://github.com/femtotrader/TALib.jl

[mrjbq7]

I'm back from my trip and would like to get to this soon. Sorry for the silence!

[mrjbq7]

I don't understand "Better layout for compatibility" commit, can you share what you were trying to improve?

[mckelvin]

@mrjbq7 The commit message is a little bit confusing. The basic idea is s/libta_lib/c_ta_lib/. If the filename begins with lib, the final generated Python module (.so) file will likelibta_lib.so, which also looks like a shared library. So I think it's better to change to the filename.

[mckelvin]

Hi @mrjbq7 , what's the latest status of this PR. I noticed that there're some similar but conflict changes in the upstream. What's your next plan. Continue this PR or re-implement from scratch? Anyway, I'd appreciate if a version of TA-Lib which I can install using pip directly, currently I have to build an in-house version (TA-Lib==0.4.10.1002) and upload that to devpi.

[briancappello]

@mckelvin I cannot speak for @mrjbq7, but in my opinion, it would be helpful if this PR were broken out: there are too many independent changes going on and this makes it difficult to review the code. I see at least four separate PRs buried in here:

• Switches from nose to pytest. Alone, this looks like a worthwhile change to me.
• Adds support for Travis. This, I broke for you because I did not realize it was buried in this PR.
• The building from source / including upstream TA-Lib vendor code.
• The shuffling around of functions / imports. (pyx -> pxi, messing with globals for BC, probably some stuff I missed.)

Broken out, it would be much easier to have focussed conversations about the specific reasons for each of your changes. That's my 2 cents.

[mckelvin]

@briancappello Can't agree more.Before splitting this large PR, I'd like to know what's happening in the upstream. There're also some tools used for generating code. It seems that @mrjbq7 is trying to use generate code for part of this PR.

[mrjbq7]

I'd appreciate separate PR's. I'm not sure what you mean by "what's happening in the upstream". If you're referring to the underlying ta-lib C library, I'm not sure. It hasn't seen a release in awhile. If you're referring to this Python wrapper, then I'm all in favor of improvements and upgrades.

The generate.py and generate_stream.py have been convenient ways of bootstrapping this wrapper by introspecting the underlying ta-lib C library header files. It also has been a nice way to make sweeping changes by updating those code generators and then running and committing a major change.

[mrjbq7]

On the nose vs py.test, I'm not sure why we would want to change, aside from personal preference. I've used 3 or 4 test runners in Python and they all seem more or less the same function-wise.

[mrjbq7]

Maybe instead of c_ta_lib.so, we just call it _ta_lib.so, dunno.

[mrjbq7]

Sorry, for small posts - I keep hitting the comment button by habit before finishing.

Regarding the vendor subtree. It's a cool idea, but I want to make sure it works on all of our platforms (Windows, Linux, and macOS) if possible.

[mckelvin]

Hi @mrjbq7 @briancappello ,

Sorry about my delayed PRs. I'm going to split this large PR into small ones:

• Merge all extensitons into one extension (Merge all extensitons into one extension #132)
• TODO: Including upstream TA-Lib vendor code and build from source if the library is not found

Personally, I'd prefer to pytest, which is helpful to write test with no boilerplate: (assert 1 == 2 instead of self.assertEqual(1, 2)). More information about nose and py.test can be found in http://mathieu.agopian.info/presentations/2015_06_djangocon_europe/ . The initial purpose why I changed the code from using nose to pytest is I was not able to run tests easily in development environment. Later I found what I had missed: I should have run python setup.py build_ext --inplace first before runing nosetests . By changing to pytest, I'd run tests easily by python setup.py test . Anyway, that's not a big deal.

Regarding the vendor subtree. It's a cool idea, but I want to make sure it works on all of our platforms (Windows, Linux, and macOS) if possible.

I've tested on Linux and macOS, but currently I don't have Windows environment. I'd appreciate if anyone would help to test under Windows. Since this feature will only be triggered when the TA-Lib C library is not installed. So users installing using the old way should not be effected.