lordgamez commented on code in PR #1853:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1853#discussion_r1708828672


##########
extensions/python/PYTHON.md:
##########
@@ -172,10 +172,11 @@ Due to some differences between the NiFi and MiNiFi C++ 
processors and implement
 - In MiNiFi C++ when the processor is stopped the stop event handling is done 
in the `notifyStop()` method which does not have the context available. Due to 
this the `def onStopped(self, context)` cannot be called in NiFi Python 
processors, so the `onStopped` method is not supported in MiNiFi C++.
 - The interface of the `ProcessContext` class is a bit more limited in MiNiFi 
C++ compared to NiFi. The available methods in `ProcessContext` are 
`getProperty`, `getStateManager`, `getName` and `getProperties`.
 - Success relationship is always present in all Python processors even if 
custom relationships are defined in the Python processor with the 
`getRelationships` method.
+- MiNiFi C++ uses a single embedded Python interpreter for all Python 
processors, so the Python processors share the same Python interpreter. This 
means that the Python processors cannot have different Python versions or use 
different Python packages. The Python packages are installed on the system or 
in a single virtualenv that is shared by all Python processors.

Review Comment:
   I don't think it will be supported in the future due to the nature of the 
implementation differences between MiNiFi's and NiFi's python support. MiNiFi 
C++ uses python C API bindings to run python code with an embedded python 
interpreter in the same MiNiFi process. To create separate interpreters with 
separate environments for each processor that would probably need separate 
processes for each processor which is not feasible. As far as I know NiFi uses 
separate processes for each python processor and the binding with the java code 
is implemented using a TCP server for communicating between the java and the 
python implementation. The point of using MiNiFi C++ with python processors 
instead of NiFi would probably be the lightweight and faster nature of the C++ 
implementation, which would be lost if we would rewrite the bindings to a 
similar TCP server communication.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to