%global _empty_manifest_terminate_build 0 Name: python-ibapi Version: 9.81.1.post1 Release: 1 Summary: Official Interactive Brokers API License: IB API Non-Commercial License or the IB API Commercial License URL: https://interactivebrokers.github.io/tws-api Source0: https://mirrors.aliyun.com/pypi/web/packages/cc/78/8f1322aa1be1fe7d747d06d445ede80141e873525120bde809ccae5484fa/ibapi-9.81.1.post1.tar.gz BuildArch: noarch %description A couple of things/definitions/conventions: - a *low level message* is some data prefixed with its size - a *high level message* is a list of fields separated by the NULL character; the fields are all strings; the message ID is the first field, the come others whose number and semantics depend on the message itself - a *request* is a message from client to TWS/IBGW (IB Gateway) - an *answer* is a message from TWS/IBGW to client How the code is organized: - *comm* module: has tools that know how to handle (eg: encode/decode) low and high level messages - *Connection*: glorified socket - *Reader*: thread that uses Connection to read packets, transform to low level messages and put in a Queue - *Decoder*: knows how to take a low level message and decode into high level message - *Client*: - knows to send requests - has the message loop which takes low level messages from Queue and uses Decoder to tranform into high level message with which it then calls the corresponding Wrapper method - *Wrapper*: class that needs to be subclassed by the user so that it can get the incoming messages The info/data flow is: - receiving: - *Connection.recv\_msg()* (which is essentially a socket) receives the packets - uses *Connection.\ *recv*\ all\_msgs()* which tries to combine smaller packets into bigger ones based on some trivial heuristic - *Reader.run()* uses *Connection.recv\_msg()* to get a packet and then uses *comm.read\_msg()* to try to make it a low level message. If that can't be done yet (size prefix says so) then it waits for more packets - if a full low level message is received then it is placed in the Queue (remember this is a standalone thread) - the main thread runs the *Client.run()* loop which: - gets a low level message from Queue - uses *comm.py* to translate into high level message (fields) - uses *Decoder.interpret()* to act based on that message - *Decoder.interpret()* will translate the fields into function parameters of the correct type and call with the correct/corresponding method of *Wrapper* class - sending: - *Client* class has methods that implement the *requests*. The user will call those request methods with the needed parameters and *Client* will send them to the TWS/IBGW. Implementation notes: - the *Decoder* has two ways of handling a message (esentially decoding the fields) - some message very neatly map to a function call; meaning that the number of fields and order are the same as the method parameters. For example: Wrapper.tickSize(). In this case a simple mapping is made between the incoming msg id and the Wrapper method: IN.TICK\_SIZE: HandleInfo(wrap=Wrapper.tickSize), - other messages are more complex, depend on version number heavily or need field massaging. In this case the incoming message id is mapped to a processing function that will do all that and call the Wrapper method at the end. For example: IN.TICK\_PRICE: HandleInfo(proc=processTickPriceMsg), Instalation notes: - you can use this to build a source distribution python3 setup.py sdist - you can use this to build a wheel python3 setup.py bdist\_wheel - you can use this to install the wheel python3 -m pip install --user --upgrade dist/ibapi-9.75.1-py3-none-any.whl %package -n python3-ibapi Summary: Official Interactive Brokers API Provides: python-ibapi BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-ibapi A couple of things/definitions/conventions: - a *low level message* is some data prefixed with its size - a *high level message* is a list of fields separated by the NULL character; the fields are all strings; the message ID is the first field, the come others whose number and semantics depend on the message itself - a *request* is a message from client to TWS/IBGW (IB Gateway) - an *answer* is a message from TWS/IBGW to client How the code is organized: - *comm* module: has tools that know how to handle (eg: encode/decode) low and high level messages - *Connection*: glorified socket - *Reader*: thread that uses Connection to read packets, transform to low level messages and put in a Queue - *Decoder*: knows how to take a low level message and decode into high level message - *Client*: - knows to send requests - has the message loop which takes low level messages from Queue and uses Decoder to tranform into high level message with which it then calls the corresponding Wrapper method - *Wrapper*: class that needs to be subclassed by the user so that it can get the incoming messages The info/data flow is: - receiving: - *Connection.recv\_msg()* (which is essentially a socket) receives the packets - uses *Connection.\ *recv*\ all\_msgs()* which tries to combine smaller packets into bigger ones based on some trivial heuristic - *Reader.run()* uses *Connection.recv\_msg()* to get a packet and then uses *comm.read\_msg()* to try to make it a low level message. If that can't be done yet (size prefix says so) then it waits for more packets - if a full low level message is received then it is placed in the Queue (remember this is a standalone thread) - the main thread runs the *Client.run()* loop which: - gets a low level message from Queue - uses *comm.py* to translate into high level message (fields) - uses *Decoder.interpret()* to act based on that message - *Decoder.interpret()* will translate the fields into function parameters of the correct type and call with the correct/corresponding method of *Wrapper* class - sending: - *Client* class has methods that implement the *requests*. The user will call those request methods with the needed parameters and *Client* will send them to the TWS/IBGW. Implementation notes: - the *Decoder* has two ways of handling a message (esentially decoding the fields) - some message very neatly map to a function call; meaning that the number of fields and order are the same as the method parameters. For example: Wrapper.tickSize(). In this case a simple mapping is made between the incoming msg id and the Wrapper method: IN.TICK\_SIZE: HandleInfo(wrap=Wrapper.tickSize), - other messages are more complex, depend on version number heavily or need field massaging. In this case the incoming message id is mapped to a processing function that will do all that and call the Wrapper method at the end. For example: IN.TICK\_PRICE: HandleInfo(proc=processTickPriceMsg), Instalation notes: - you can use this to build a source distribution python3 setup.py sdist - you can use this to build a wheel python3 setup.py bdist\_wheel - you can use this to install the wheel python3 -m pip install --user --upgrade dist/ibapi-9.75.1-py3-none-any.whl %package help Summary: Development documents and examples for ibapi Provides: python3-ibapi-doc %description help A couple of things/definitions/conventions: - a *low level message* is some data prefixed with its size - a *high level message* is a list of fields separated by the NULL character; the fields are all strings; the message ID is the first field, the come others whose number and semantics depend on the message itself - a *request* is a message from client to TWS/IBGW (IB Gateway) - an *answer* is a message from TWS/IBGW to client How the code is organized: - *comm* module: has tools that know how to handle (eg: encode/decode) low and high level messages - *Connection*: glorified socket - *Reader*: thread that uses Connection to read packets, transform to low level messages and put in a Queue - *Decoder*: knows how to take a low level message and decode into high level message - *Client*: - knows to send requests - has the message loop which takes low level messages from Queue and uses Decoder to tranform into high level message with which it then calls the corresponding Wrapper method - *Wrapper*: class that needs to be subclassed by the user so that it can get the incoming messages The info/data flow is: - receiving: - *Connection.recv\_msg()* (which is essentially a socket) receives the packets - uses *Connection.\ *recv*\ all\_msgs()* which tries to combine smaller packets into bigger ones based on some trivial heuristic - *Reader.run()* uses *Connection.recv\_msg()* to get a packet and then uses *comm.read\_msg()* to try to make it a low level message. If that can't be done yet (size prefix says so) then it waits for more packets - if a full low level message is received then it is placed in the Queue (remember this is a standalone thread) - the main thread runs the *Client.run()* loop which: - gets a low level message from Queue - uses *comm.py* to translate into high level message (fields) - uses *Decoder.interpret()* to act based on that message - *Decoder.interpret()* will translate the fields into function parameters of the correct type and call with the correct/corresponding method of *Wrapper* class - sending: - *Client* class has methods that implement the *requests*. The user will call those request methods with the needed parameters and *Client* will send them to the TWS/IBGW. Implementation notes: - the *Decoder* has two ways of handling a message (esentially decoding the fields) - some message very neatly map to a function call; meaning that the number of fields and order are the same as the method parameters. For example: Wrapper.tickSize(). In this case a simple mapping is made between the incoming msg id and the Wrapper method: IN.TICK\_SIZE: HandleInfo(wrap=Wrapper.tickSize), - other messages are more complex, depend on version number heavily or need field massaging. In this case the incoming message id is mapped to a processing function that will do all that and call the Wrapper method at the end. For example: IN.TICK\_PRICE: HandleInfo(proc=processTickPriceMsg), Instalation notes: - you can use this to build a source distribution python3 setup.py sdist - you can use this to build a wheel python3 setup.py bdist\_wheel - you can use this to install the wheel python3 -m pip install --user --upgrade dist/ibapi-9.75.1-py3-none-any.whl %prep %autosetup -n ibapi-9.81.1.post1 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "\"/%h/%f\"\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "\"/%h/%f\"\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "\"/%h/%f\"\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "\"/%h/%f\"\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "\"/%h/%f.gz\"\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-ibapi -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Thu Jun 08 2023 Python_Bot - 9.81.1.post1-1 - Package Spec generated