Hi Julian, sorry for that ... I sort of feel like last week was totally nuts with Emails, Twitter, LinkedIn, Xing, Facebook, Slack and my Phone (
Must have slipped my mind. But happy to help ;) Chris Am 28.04.19, 13:06 schrieb "Julian Feinauer" <[email protected]>: Right, I asked you on one email to help me out with that :) You're the gosu Von meinem Mobiltelefon gesendet -------- Ursprüngliche Nachricht -------- Betreff: Re: [python] Experimental version of plc4py available for testing! Von: Christofer Dutz An: [email protected] Cc: That's where the maven-dependency-plugin "copy" goal comes in ... that's what it does. Chris Am 28.04.19, 11:54 schrieb "Julian Feinauer" <[email protected]>: Hi Chris, Yes indeed it is. Therefore I need to copy the server jar to the python module. J Von meinem Mobiltelefon gesendet -------- Ursprüngliche Nachricht -------- Betreff: Re: [python] Experimental version of plc4py available for testing! Von: Christofer Dutz An: [email protected] Cc: Hi Julian, Ok ... now I know where we might have been not on the same page ... guess now I know what you want to do. But I still think it's still more a packaging thing and the interop server should remain in the java section. Isn't the "python-s7-driver": - The java interop server - The java s7 driver - The python proxy driver core - Some custom python code that glues together everything Chris Am 28.04.19, 09:43 schrieb "Julian Feinauer" <[email protected]>: Hi Chris, I think we have again some kind of misunderstanding... I think we are considereing two different use cases. You consider the "proxy" use case where I start a server somewhere and expose the port and connect from somewhere else to this server and use it as proxy. Fine. I had another use case in mind. While we do not have native drivers in other languages I would use the proxy implicitly to have a working version of drivers for other languages. For the python server for example: If you instantiate the (Python) DriverManager it starts a java interop server in the background as subprocess. For each (Python) Connection instance it generates a Client to this server. This allows Python users to simply use PLC4X the way "we" do it in java without thinking about the proxy stuff or so. Does it make that more clear to you? Julian Am 26.04.19, 18:38 schrieb "Christofer Dutz" <[email protected]>: Hi Julian, I don't quite understand why you want to have the server.jar to the python part. It's built in java and you should be able to not only connect to the java-based server not only from python, cpp or even Java. Do you want to copy it there too? Ideally I would see a Server and Client implementation using thrift as general protocol in every language so you could connect every type of client with every type of server. Chris Am 26.04.19, 16:23 schrieb "Julian Feinauer" <[email protected]>: Hi, fort he general information... lovely Chris updated the build to build thrift and really generate the sources with the build. Thank you very much for that Chris! I just updated the necessary python code to also use the (on-the-fly) generated python classes and everything works again. @Chris: The only thing which should / could be done is to copy the interop server jar to the plc4py module in the init phase or something. Because it relies on that to work. And I think it is better to "pull" it from the plc4py module than to "push" it after the build of the interop-server module, as otherwise the interop-server needs to know "all" proxy implementations. What do you think? Julian Am 23.04.19, 12:41 schrieb "Christofer Dutz" <[email protected]>: Hi Julian, And I'll replace the checked-in code in the java module with the execution of a maven plugin as part of the build. Chris Am 23.04.19, 12:30 schrieb "Julian Feinauer" <[email protected]>: Hi, I see... well, we can do that, no objections... I have just no idea how this whole "directory" resolution stuff works. But feel free to adapt it in my branch. Julian PS.: Or should I simply merge it into develop for all to play around? Am 23.04.19, 10:42 schrieb "Christofer Dutz" <[email protected]>: Hi Julian, I just checked out your feature-branch and can now see the plc4py directory. So as mentioned in another thread, I think it would be great to have a similar setup as with the other languages. Then we would have a "plc4py/api" and a "plc4py/proxy" module (As we are hoping to have "plc4py/s7" and alike in the near future). The "proxy" driver could then run the thrift generation stuff ... What do you think? Chris Am 23.04.19, 10:00 schrieb "Julian Feinauer" <[email protected]>: For what? I just added a maven module for plc4py.. so feel free to add the "copy the jar from interop-server"-thing... as you can do that without googling, I know :D Am 23.04.19, 09:59 schrieb "Christofer Dutz" <[email protected]>: Raising my hand ... :-) Chris Am 23.04.19, 09:38 schrieb "Julian Feinauer" <[email protected]>: Oh, and just one or two more comments. I would love if someone who knows how modules in maven work (setup.py ...) could help a bit out here (perhaps copy the lib automatically during maven build). And then, I'll create the PR as soon as someone else has tried it out : ) Julian Am 21.04.19, 19:28 schrieb "Julian Feinauer" <[email protected]>: Hi Chris, No offense. Just wanted to start a discussion and get some feedback before a pr :) Julian Von meinem Mobiltelefon gesendet -------- Ursprüngliche Nachricht -------- Betreff: Re: [python] Experimental version of plc4py available for testing! Von: Christofer Dutz An: [email protected] Cc: Hi Julian, Great stuff :-) Well how about adding the plc4py to develop and work on the API from there? I mean you currently can't really use the c++ implementation sure to a lack of drivers (so this concept would also be great for that). The connection to the Java thrift server could be treated as a proxy and therefore the driver could be named something accordingly. Then we'd have the API module and a proxy driver implementation. Guess this setup should work for all languages. And let's see if the news on Tuesday will wash ashore someone interested and deeply into python that could help fine tune the API? Chris Outlook für Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Julian Feinauer <[email protected]> Sent: Sunday, April 21, 2019 2:34:58 PM To: [email protected] Subject: [python] Experimental version of plc4py available for testing! Hi all, as some of you may know, with the interop server (PLC4X-111) we are working towards providing language bindings for other languages. And, as I thought I should learn python at some point, I decided to play around with the python bindings. So, in my branch [1] you find the experimental implementation of a python api based on the interop server. There are also some tests which pass and the mt / it where tried against my local s7 here and work also. All you need to run everything is (aside from installing the necessary dependencies, which are mainly thrift in version 0.12.0) is written in the README.md. I would be very grateful if someone tries this out and gives feedback. And we should also talk about some things like. * How are these packages created in python, how to integrate this in our build? * How to manage the dependencies (there are many systems in python as I learned) * Is this API okay or not python-esque enough? Thanks all of you for your feedback. And I would even suggest to prepare an experimental version of this with the next release to some python repos to let people play around with it in python. This could really be a killer feature to bring others to the community. Best Julian PS.: DISCLAIMER: That I work with Python does NOT mean that I like python, just to be clear! [1] https://github.com/apache/incubator-plc4x/tree/feature/PLC4X-111-interop-server
