Develop Reference

ta-lib replit python install problem, ERROR: No matching distribution found for talib-binary

I use it on my windows machine by downloading its binary. I also use it in Heroku from its herokus build pack. I don't know what operating system replit use. But I try every possible commed like.
!pip install ta-lib
!pip install talib-binary
It's not working with replit. I thought it work like google co-lab but its not the same.
can anyone use TA-LIB with replit. if so. How you install it?

Getting TA-Lib work on Replit
(by installing it from sources)
Create a new replit with Nix toolset with a Python template.
In main.py write:
import talib
print (talib.__ta_version__)
This will be our test case. If ta-lib is installed the python main.py (executed in Shell) will return something like:
$ python main.py
b'0.6.0-dev (Jan 1 1980 00:00:00)'
We need to prepare a tools for building TA-Lib sources. There is a replit.nix file in your project's root folder (in my case it was ~/BrownDutifulLinux). Every time you execute a command like cmake the Nix reports that:
cmake: command not installed. Multiple versions of this command were found in Nix.
Select one to run (or press Ctrl-C to cancel):
cmake.out
cmakeCurses.out
cmakeWithGui.out
cmakeMinimal.out
cmake_2_8.out
If you select cmake.out it will add a record about it into the replit.nix file. And next time you call cmake, it will know which cmake version to launch. Perhaps you may manually edit replit.nix file... But if you're going to add such commands in a my way, note that you must execute them in Shell in your project root folder as replit.nix file is located in it. Otherwise Nix won't remember your choice.
After all my replit.nix file (you may see its content with cat replit.nix) content was:
{ pkgs }: {
deps = [
pkgs.libtool
pkgs.automake
pkgs.autoconf
pkgs.cmake
pkgs.python38Full
];
env = {
PYTHON_LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath [
# Needed for pandas / numpy
pkgs.stdenv.cc.cc.lib
pkgs.zlib
# Needed for pygame
pkgs.glib
# Needed for matplotlib
pkgs.xorg.libX11
];
PYTHONBIN = "${pkgs.python38Full}/bin/python3.8";
LANG = "en_US.UTF-8";
};
}
Which means I executed libtool, autoconf, automake and cmake in Shell. I always choose a generic suggestion from Nix, without a specific version. Note: some commands may report errors as we executing them in a wrong way just to add to a replit.nix.
3.
Once build tools are set up we need to get and build TA-Lib C library sources. To do that execute in Shell:
git clone https://github.com/TA-Lib/ta-lib.git
then
cd ta-lib/
libtoolize
autoreconf --install
./configure
If configure script is completed without any problems, build the library with:
make -j4
It will end up with some compilation errors, but they are related to some additional tools which are used to add new TA-Lib indicators and build at the end, but not the library itself. The library will be successfully compiled and you should be able to see it with:
$ ls ./src/.libs/
libta_lib.a libta_lib.lai libta_lib.so.0
libta_lib.la libta_lib.so libta_lib.so.0.0.0
Now we have our C library built, but we can't install it to a system default folders. So we have to use the library as is from the folders where it was build. All we need is just one more additional preparation:
mkdir ./include/ta-lib
cp ./include/*.h ./include/ta-lib/
This will copy a library headers to a subfolder, as they are designed to be used from a such subfolder (which they don't have due to impossibility to perform the installation step).
4.
Now we have TA-Lib C library built and prepared to be used locally from its build folders. All we need after that - is to compile the Python wrapper for it. But Python wrapper will look for a library only in system default folders, so we need to instruct it where our library is.
To do this, execute pwd and remember the absolute path to your project's root folder. In my case it was:
/home/runner/FormalPleasedOffice
Then adjust the paths (there are two) in a following command to lead to your project path:
TA_INCLUDE_PATH=/home/runner/FormalPleasedOffice/ta-lib/include/ TA_LIBRARY_PATH=/home/runner/FormalPleasedOffice/ta-lib/src/.libs/ pip install ta-lib
This is one line command, not a two commands.If the paths would be shorter it would look like:
TA_INCLUDE_PATH=/path1/ TA_LIBRARY_PATH=/path2/ pip install ta-lib.
After execution of this command the wrapper will be installed with two additional paths where it will look for a library and its header files.
That's actually all.
An alternative way would be to clone the wrapper sources, edit its setup.py and install wrapper manually. Just for the record this would be:
cd ~/Your_project
git clone https://github.com/mrjbq7/ta-lib.git ta-lib-wrapper
cd ta-lib-wrapper
Here edit the setup.py. Find the lines include_dirs = [ and library_dirs = [ and append your paths to these lists. Then you just need to:
python setup.py build
pip install .
Note the dot at the end.
5.
Go to the project's folder and try our python script:
$python main.py
b'0.6.0-dev (Jan 1 1980 00:00:00)'
Bingo!

The #truf answer is correct.
after you add the
pkgs.libtool
pkgs.automake
pkgs.autoconf
pkgs.cmake
in the replit.nix dippendancies.
git clone https://github.com/TA-Lib/ta-lib.git
cd ta-lib/
libtoolize
autoreconf --install
./configure
make -j4
mkdir ./include/ta-lib
cp ./include/*.h ./include/ta-lib/
TA_INCLUDE_PATH=/home/runner/FormalPleasedOffice/ta-lib/include/ TA_LIBRARY_PATH=/home/runner/FormalPleasedOffice/ta-lib/src/.libs/ pip install ta-lib
Note : FormalPleasedOffice should be your project name
Done.
Here is the youtube video :
https://www.youtube.com/watch?v=u20y-nUMo5I

Error installing/compiling grpc on Ubuntu

I have protobuf compiler version 3.0 and need to install grpc and grpc python plugin. Following the tutorial, I added deb http://http.debian.net/debian jessie-backports main to my sources.list file and did sudo apt-get update and sudo apt-get install libgrpc-dev which returned
Package libgrpc-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'libgrpc-dev' has no installation candidate
So, I decided to compile it from source as mentioned in INSTALL notes and did:
$ git clone https://github.com/grpc/grpc.git
$ cd grpc
$ git submodule update --init
$ make
$ [sudo] make install
However, on the make step, I get
[MAKE] Generating cache.mk
make: Circular /home/vagrant/grpc2/grpc/libs/opt/libboringssl.a <- /home/vagrant/grpc2/grpc/libs/opt/libboringssl.a dependency dropped.
[C] Compiling third_party/boringssl/crypto/bio/connect.c
third_party/boringssl/crypto/bio/connect.c: In function 'split_host_and_port':
third_party/boringssl/crypto/bio/connect.c:127:17: error: declaration of 'close' shadows a global declaration [-Werror=shadow]
cc1: all warnings being treated as errors
make: *** [/home/vagrant/grpc2/grpc/objs/opt/third_party/boringssl/crypto/bio/connect.o] Error 1
On switching to the release-0_11 branch, running make results in
[HOSTCXX] Compiling src/compiler/csharp_generator.cc
src/compiler/csharp_generator.cc:47:43: error: 'google::protobuf::compiler::csharp::GetUmbrellaClassName' has not been declared
src/compiler/csharp_generator.cc: In function 'void grpc_csharp_generator::{anonymous}::GenerateServiceDescriptorProperty(grpc::protobuf::io::Printer*, const ServiceDescriptor*)':
src/compiler/csharp_generator.cc:237:62: error: 'GetUmbrellaClassName' was not declared in this scope
make: *** [/home/vagrant/grpc2/grpc/objs/opt/src/compiler/csharp_generator.o] Error 1
I can't figure out how to install this. Any help would be appreciated.

For me the issue got fixed after i made change in the file as:
diff --git a/src/compiler/csharp_generator.cc
b/src/compiler/csharp_generator.cc
index 7b497df..5a8746d 100644
--- a/src/compiler/csharp_generator.cc
+++ b/src/compiler/csharp_generator.cc
## -44,7 +44,7 ##
using google::protobuf::compiler::csharp::GetFileNamespace;
using google::protobuf::compiler::csharp::GetClassName;
-using google::protobuf::compiler::csharp::GetUmbrellaClassName;
+using google::protobuf::compiler::csharp::GetReflectionClassName;
using grpc::protobuf::FileDescriptor;
using grpc::protobuf::Descriptor;
using grpc::protobuf::ServiceDescriptor;
## -234,7 +234,7 ## void GenerateServiceDescriptorProperty(Printer* out, const ServiceDescriptor *se
out->Print("public static global::Google.Protobuf.Reflection.ServiceDescriptor Descriptor\n");
out->Print("{\n");
out->Print(" get { return $umbrella$.Descriptor.Services[$index$]; }\n",
- "umbrella", GetUmbrellaClassName(service->file()), "index",
+ "umbrella", GetReflectionClassName(service->file()), "index",
index.str());
out->Print("}\n");
out->Print("\n");
More specifically, please open the file src/compiler/csharp_generator.cc and replace all references of GetUmbrellaClassName by GetReflectionClassName

Working backwards:
for release-0_11: it looks like you're trying to compile against the most recent protobuf. Since we're both in development right now there's occasional breakage - but grpc does track the version of protobuf it's tested against in third_party/protobuf. Try checking out and installing that version. I filed https://github.com/grpc/grpc/issues/4697 to update to the latest protobuf 3.0 version.
for master from github: which compiler and OS are you using? I recently checked in the boringssl integration work, so it's fresh, and not nearly as battle-tested. I'd like to get it battle-tested. That said, if you do a 'make EMBED_OPENSSL=false' then things should work out for you.
for the debian package problem: I'm not sure what's going on. I'm happy to try and spin up a VM with your OS and repro if you can let me know which OS it is.

PyQt5 error during "python3 configure.py": fatal error: 'qgeolocation.h' file not found

MAC OSX 10.9, Python 3.5, sip-4.17, PyQt-gpl-5.5.1, Qt5.5.1
Hi,
trying to build PyQt on my system I did the following steps:
download/install Qt5.5.1 libraries
download/unpack SIP
download/unpack PyQt
install SIP:
python3 configure.py -d /Library/Python/3.5/site-packages --arch x86_64
make
sudo make install
tried to install PyQt:
python3 configure.py -d /Library/Python/3.5/site-packages
--qmake /.../Qt5.5.1/5.5/clang_64/bin/qmake
Configuration stopped with:
/Users/werner/OpenSource/PyQt/sip/QtPositioning/qgeolocation.sip:28:10:
fatal >error: 'qgeolocation.h' file not found
#include <qgeolocation.h>
^
1 error generated.
make[1]: *** [sipQtPositioningcmodule.o] Error 1
make: *** [sub-QtPositioning-make_first-ordered] Error 2
I tried to finish installation doing
make
sudo make install
anyway. But the installation doesn't seem to be complete (e.g. uic, pyuic5 are missing). Here is what my installation directory looks like:
>ls /Library/Python/3.5/site-packages/PyQt5
QtBluetooth.so QtSensors.so
QtCore.so QtSerialPort.so
QtDBus.so QtSql.so
QtDesigner.so QtSvg.so
QtGui.so QtTest.so
QtHelp.so QtWebKit.so
QtMacExtras.so QtWebKitWidgets.so
QtMultimedia.so QtWidgets.so
QtMultimediaWidgets.so QtXml.so
QtNetwork.so QtXmlPatterns.so
QtOpenGL.so _QOpenGLFunctions_2_0.so
QtPrintSupport.so _QOpenGLFunctions_2_1.so
QtQml.so _QOpenGLFunctions_4_1_Core.so
QtQuick.so
I couldn't find any useful information when searching for other discussions, so I hope someone can give me a hint on what I'm (maybe stupidly) doing wrong. Thank you for taking the time to read this.

If you don't need this module, the better way to solve that is disabling it on configure.
python configure.py --disable=QtPositioning

Just yesterday, I also met such a problem. And this is what I do to solve it:
Create a header file qgeolocation.h in /PyQt-gpl-5.5.1/QtPositioning, and copy the content into it from this website. Then I go sudo make and sudo make install successfully.
Though I do not know whether it is right to solve this problem, fortunately, I installed the PyQt and entered eric6. Hope you make successfully, too.

Adding the location.h header file for me on OSX 10.11.1.
I had the problem in both PyQt-gpl-5.5.1 and PyQt-gpl-5.5.2, but after adding the
file, was able to build.

The way of creating a qgeolocation.h in /PyQt-gpl-5.5.1/QtPositioning worked for me. The QtPositioning.so was created.

You can also take the header file from your qt source folder (you have installed the source files together with binaries, right?), it is located here:
/Src/qtlocation/src/positioning/qgeolocation.h
and then just copy it into:
/PyQt-gpl-X.X.X/QtPositioning/qgeolocation.h
as follows. It should solve the problem in 99.9% cases.

How to fix "python does not have .gnu.prelink_undo section"

I need to package a virtualenv as an rpm. I found a sample spec file for plone here
My project uses python 2.7 and for that I've built python from source. Therefore I changed some of the spec file to
/usr/local/bin/virtualenv-3.4 --no-site-packages --distribute %{_builddir}/usr/local/virtualenvs/%{shortname}
I'm getting the following error on rpmbuild -bb requirements.spec
+ /usr/sbin/prelink -u /var/lib/jenkins/rpmbuild/BUILDROOT/requirements-1.0-1.x86_64/usr/local/virtualenvs/requirements/bin/python
/usr/sbin/prelink: /var/lib/jenkins/rpmbuild/BUILDROOT/requirements-1.0-1.x86_64/usr/local/virtualenvs/requirements/bin/python does not have .gnu.prelink_undo section
I'm assuming I need to rebuild python and enable the prelinking during the ./configure. How can I do that?

I had a similar issue recently with a SPEC file that was also based on this example from plone.
In my case I'm using python27 RPMs from IUS repository and want to avoid building it from source.
My workaround was to disable prelink completely in my SPEC file:
add this: %define __prelink_undo_cmd %{nil}
comment out this:
# # This avoids prelink & RPM helpfully breaking the package signatures:
# /usr/sbin/prelink -u $RPM_BUILD_ROOT/usr/local/virtualenvs/%{shortname}/bin/python

Python module development workflow - setup and build [duplicate]

I'm developing my own module in python 2.7. It resides in ~/Development/.../myModule instead of /usr/lib/python2.7/dist-packages or /usr/lib/python2.7/site-packages. The internal structure is:
/project-root-dir
/server
__init__.py
service.py
http.py
/client
__init__.py
client.py
client/client.py includes PyCachedClient class. I'm having import problems:
project-root-dir$ python
Python 2.7.2+ (default, Jul 20 2012, 22:12:53)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from server import http
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "server/http.py", line 9, in <module>
from client import PyCachedClient
ImportError: cannot import name PyCachedClient
I didn't set PythonPath to include my project-root-dir, therefore when server.http tries to include client.PyCachedClient, it tries to load it from relative path and fails. My question is - how should I set all paths/settings in a good, pythonic way? I know I can run export PYTHONPATH=... in shell each time I open a console and try to run my server, but I guess it's not the best way. If my module was installed via PyPi (or something similar), I'd have it installed in /usr/lib/python... path and it'd be loaded automatically.
I'd appreciate tips on best practices in python module development.

My Python development workflow
This is a basic process to develop Python packages that incorporates what I believe to be the best practices in the community. It's basic - if you're really serious about developing Python packages, there still a bit more to it, and everyone has their own preferences, but it should serve as a template to get started and then learn more about the pieces involved. The basic steps are:
Use virtualenv for isolation
setuptools for creating a installable package and manage dependencies
python setup.py develop to install that package in development mode
virtualenv
First, I would recommend using virtualenv to get an isolated environment to develop your package(s) in. During development, you will need to install, upgrade, downgrade and uninstall dependencies of your package, and you don't want
your development dependencies to pollute your system-wide site-packages
your system-wide site-packages to influence your development environment
version conflicts
Polluting your system-wide site-packages is bad, because any package you install there will be available to all Python applications you installed that use the system Python, even though you just needed that dependency for your small project. And it was just installed in a new version that overrode the one in the system wide site-packages, and is incompatible with ${important_app} that depends on it. You get the idea.
Having your system wide site-packages influence your development environment is bad, because maybe your project depends on a module you already got in the system Python's site-packages. So you forget to properly declare that your project depends on that module, but everything works because it's always there on your local development box. Until you release your package and people try to install it, or push it to production, etc... Developing in a clean environment forces you to properly declare your dependencies.
So, a virtualenv is an isolated environment with its own Python interpreter and module search path. It's based on a Python installation you previously installed, but isolated from it.
To create a virtualenv, install the virtualenv package by installing it to your system wide Python using easy_install or pip:
sudo pip install virtualenv
Notice this will be the only time you install something as root (using sudo), into your global site-packages. Everything after this will happen inside the virtualenv you're about to create.
Now create a virtualenv for developing your package:
cd ~/pyprojects
virtualenv --no-site-packages foobar-env
This will create a directory tree ~/pyprojects/foobar-env, which is your virtualenv.
To activate the virtualenv, cd into it and source the bin/activate script:
~/pyprojects $ cd foobar-env/
~/pyprojects/foobar-env $ . bin/activate
(foobar-env) ~/pyprojects/foobar-env $
Note the leading dot ., that's shorthand for the source shell command. Also note how the prompt changes: (foobar-env) means your inside the activated virtualenv (and always will need to be for the isolation to work). So activate your env every time you open a new terminal tab or SSH session etc..
If you now run python in that activated env, it will actually use ~/pyprojects/foobar-env/bin/python as the interpreter, with its own site-packages and isolated module search path.
A setuptools package
Now for creating your package. Basically you'll want a setuptools package with a setup.py to properly declare your package's metadata and dependencies. You can do this on your own by by following the setuptools documentation, or create a package skeletion using Paster templates. To use Paster templates, install PasteScript into your virtualenv:
pip install PasteScript
Let's create a source directory for our new package to keep things organized (maybe you'll want to split up your project into several packages, or later use dependencies from source):
mkdir src
cd src/
Now for creating your package, do
paster create -t basic_package foobar
and answer all the questions in the interactive interface. Most are optional and can simply be left at the default by pressing ENTER.
This will create a package (or more precisely, a setuptools distribution) called foobar. This is the name that
people will use to install your package using easy_install or pip install foobar
the name other packages will use to depend on yours in setup.py
what it will be called on PyPi
Inside, you almost always create a Python package (as in "a directory with an __init__.py) that's called the same. That's not required, the name of the top level Python package can be any valid package name, but it's a common convention to name it the same as the distribution. And that's why it's important, but not always easy, to keep the two apart. Because the top level python package name is what
people (or you) will use to import your package using import foobar or from foobar import baz
So if you used the paster template, it will already have created that directory for you:
cd foobar/foobar/
Now create your code:
vim models.py
models.py
class Page(object):
"""A dumb object wrapping a webpage.
"""
def __init__(self, content, url):
self.content = content
self.original_url = url
def __repr__(self):
return "<Page retrieved from '%s' (%s bytes)>" % (self.original_url, len(self.content))
And a client.py in the same directory that uses models.py:
client.py
import requests
from foobar.models import Page
url = 'http://www.stackoverflow.com'
response = requests.get(url)
page = Page(response.content, url)
print page
Declare the dependency on the requests module in setup.py:
install_requires=[
# -*- Extra requirements: -*-
'setuptools',
'requests',
],
Version control
src/foobar/ is the directory you'll now want to put under version control:
cd src/foobar/
git init
vim .gitignore
.gitignore
*.egg-info
*.py[co]
git add .
git commit -m 'Create initial package structure.
Installing your package as a development egg
Now it's time to install your package in development mode:
python setup.py develop
This will install the requests dependency and your package as a development egg. So it's linked into your virtualenv's site-packages, but still lives at src/foobar where you can make changes and have them be immediately active in the virtualenv without re-installing your package.
Now for your original question, importing using relative paths: My advice is, don't do it. Now that you've got a proper setuptools package, that's installed and importable, your current working directory shouldn't matter any more. Just do from foobar.models import Page or similar, declaring the fully qualified name where that object lives. That makes your source code much more readable and discoverable, for yourself and other people that read your code.
You can now run your code by doing python client.py from anywhere inside your activated virtualenv. python src/foobar/foobar/client.py works just as fine, your package is properly installed and your working directory doesn't matter any more.
If you want to go one step further, you can even create a setuptools entry point for your CLI scripts. This will create a bin/something script in your virtualenv that you can run from the shell.
setuptools console_scripts entry point
setup.py
entry_points='''
# -*- Entry points: -*-
[console_scripts]
run-fooobar = foobar.main:run_foobar
''',
client.py
def run_client():
# ...
main.py
from foobar.client import run_client
def run_foobar():
run_client()
Re-install your package to activate the entry point:
python setup.py develop
And there you go, bin/run-foo.
Once you (or someone else) installs your package for real, outside the virtualenv, the entry point will be in /usr/local/bin/run-foo or somewhere simiar, where it will automatically be in $PATH.
Further steps
Creating a release of your package and uploading it PyPi, for example using zest.releaser
Keeping a changelog and versioning your package
Learn about declaring dependencies
Learn about Differences between distribute, distutils, setuptools and distutils2
Suggested reading:
The Hitchhiker’s Guide to Packaging
The pip cookbook

So, you have two packages, the first with modules named:
server # server/__init__.py
server.service # server/service.py
server.http # server/http.py
The second with modules names:
client # client/__init__.py
client.client # client/client.py
If you want to assume both packages are in you import path (sys.path), and the class you want is in client/client.py, then in you server you have to do:
from client.client import PyCachedClient
You asked for a symbol out of client, not client.client, and from your description, that isn't where that symbol is defined.
I personally would consider making this one package (ie, putting an __init__.py in the folder one level up, and giving it a suitable python package name), and having client and server be sub-packages of that package. Then (a) you could do relative imports if you wanted to (from ...client.client import something), and (b) your project would be more suitable for redistribution, not putting two very generic package names at the top level of the python module hierarchy.