diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-ibapi.spec | 339 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 341 insertions, 0 deletions
@@ -0,0 +1 @@ +/ibapi-9.81.1.post1.tar.gz diff --git a/python-ibapi.spec b/python-ibapi.spec new file mode 100644 index 0000000..357c04c --- /dev/null +++ b/python-ibapi.spec @@ -0,0 +1,339 @@ +%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.nju.edu.cn/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 May 18 2023 Python_Bot <Python_Bot@openeuler.org> - 9.81.1.post1-1 +- Package Spec generated @@ -0,0 +1 @@ +fa8f7acfcde1002664c315bef1b8f252 ibapi-9.81.1.post1.tar.gz |