pyzmq | PyZMQ : Python bindings for zeromq | Reactive Programming library

Q :
_{Is it safe to use inproc://* between a thread and asyncio task in this way?""}

A :
First and foremost, I might be awfully wrong (not only here), yet having worked with ZeroMQ since native API 2.1.1+ I dare claim that unless newer "improvements" got lost the core principles ( ZeroMQ ZMTP/RFC-documented properties for building legal implementation of the still valid ZMTP-arsenal ), the answer here shall be YES, as much as the newer releases of pyzmq-binding kept all mandatory properties of the inproc:-Transport-Class without a compromise.

Q :
_{" The 0MQ context is thread safe and I'm not sharing sockets between the thread and the asyncio task, so I would say in general that this is thread safe, right? "}

A :
Here my troubles start - ZeroMQ implementations were since ever developed based on Martin SUSTRIK's & Pieter HINTJENS' Zen-of-Zero -- i.e. also as Zero-sharing -- so never sharing was the principle ( though "share"-zmq.Context-instances were no problem to be used from different threads, to the contrary of the zmq.Socket-instances )

Python (since ever & still valid in 2022-Q1) used to use & still uses a total [CONCURRENT]-code-execution avoider -- prevented by GIL-lock, which principally avoids any & all kinds of problems, arising from [CONCURRENT]-code-execution to never happen insider Python GIL-lock re-[SERIAL]-ised flow of code-execution, so even if the asyncio-part is built as a pythonic (non-destructive) part of the ecosystem, your code shall never "meet" any kind of concurrency-related issue, as the unless it gains GIL-lock, it does nothing but "hanging in NOP-s cracking" ( nuts-cracking in idle loop ).

Being inside the same process, there seems no advantage to spawn another Context-instance at all ( this used to be the rock-solid certainty since ever, not to ever increase any kind of overheads - Zen-of-Zero _{( almost )}Zero-overhead ... ). The Sig/Msg core engine was, if performance or latency needs required, powered with more zmq.Context( IOthreads ) upon instantiations, yet these were zmq.Context-owned, not Python-GIL-governed/(b)locked threads, so the performance was pretty well scalable, without wasting any RAM/HWM/buffers/...-resources, without growing any overheads and very efficient, as the IO-threads were co-located for only indeed I/O-work, so not needed for inproc:-( protocol-less )-Transport-Class at all )

Q :
_{" Or am I missing something that I should consider? "}

A :
Mixing asyncio, O/S-signals ( that are well documented how they interact with native ZeroMQ API ) and other layers of complexity is for sure possible, yet it comes at a cost - it makes the use-case less and less readable and more and more prone to conceptual-gaps and similar hard to decode "errors".

I remember using Tkinter-mainloop() as a cost-wise very cheap and a super-stable framework for rapid-prototyping an MVC-{ M-odel, V-isual, C-ontroller }-parts of many-actors' indeed distributed-system applications in Python. There were Zerop-problems to use ZeroMQ with a single Context-instance, passing the references of the respective AccessNodes' into whatever amount of event-handlers, supposing we kept the ZeroMQ Zen-of-Zero, i.e. no to "share" (meaning no two parts "use" (compete to use) one and the same AccessPoint "one-over-another")

This all was designed-in, at "Zero-cost", by the ZeroMQ by-definition, so unless spoilt in some later phase, re-wrapping a re-wrapped native API, all this ought still work in 2022-Q1, ought it not?

So in case anyone comes across similar for any reason with me encountering this probably due getting a new machine and IT doing their voodoo magic transferring my old stuff to this new machine.

Anyhow, there were a bunch of things I still needed to install after I got my new machine and i am not able to exactly pin point what caused issues from my question but in the end I was able to resolve. Follow me there below ...

Checking out my python.exe files I found 2 paths. First one added as environment variable

1. C:\Users-----\AppData\Local\Programs\Python\Python310
2. C:\Users----\AppData\Roaming\Python\Python310\

Second one not added. Adding roaming version to path variables did not solve the issue and gave additional errors instead: Fatal error in launcher: Unable to create process using '"C:\Program Files\Python310\python.exe"

So

1. I uninstalled python (done that before didnt help doing just that alone)

2. Deleted all environment variables pointing to python (here is what environment variables are just in case - https://www.computerhope.com/issues/ch000549.htm)

3. Uninstalled python extension from VS code (https://marketplace.visualstudio.com/items?itemName=ms-python.python)

4. Deleted Python folders mentioned in the two paths above

5. Then reinstalled python (clicked add to path during installation)

6. Reinstalled VS code python extension

7. Everything works now.

Best of luck

After a few days I was able to find the solution

Firstly, my code needed to be fixed to correctly call the params needed with the proper name

I don't think ipykernel is compatible with 3.10.

Below is the message I receive when I try to install ipykernel with the following command: conda install -c anaconda ipykernel

Had the same problem. My solution is --

First uninstall all jupyter related modules:

applaunchservices appears to be Apple-only:

Simple package for registering an app with apple Launch Services to handle UTI and URL. See Apple documentations for details.

I suspect you don't need that, either. Did you create your requirements.txt from a pip freeze? There's likely a bunch of stuff in there you don't need.

I suggest you review that file and remove anything you aren't directly depending on. pip will find transitive dependencies (dependencies your dependencies depend on) and install them automatically.

Prune that file, commit, and redeploy.

Consider creating a separate environment, e.g.,

Q : _{What is the expected behaviour after setting these socket options ?}

A :
well,
there are two-fold effect of the said settings. One, that actually works for your setup goals ( i.e. going & sending (most probably ZMTP/3.1) ZMTP_PING connection-oriented service-sublayer "ZMTP/3.1-service-packets" and reciprocally, not sure, but most often, adequately formed "ZMTP/{3.1|2.x|1.0}-service-packets" (hopefully delivered) back. These "service-packets" are visible on the wire-line (if present - an inproc://-transport-class and vmci://-transport-class too have no actual wire a typical user can hook-on and sniff-traffic in, but some kind of pointer-acrobatics used for RAM-mapping), so a protocol-analyser will "see" them id decodes like this:

Streamlit share runs the app in a linux environment meaning there is no pywin32 because this is for windows.

Delete the pywin32 from the requirements file and also the pywinpty==1.1.6 for the same reason.

After deleting these requirements re-deploy your app and it will work.