Re: [DISCUSS] Rename Fields -> Tags?

[Otto Fowler]

 if we had already had one before

From: Otto Fowler  
Reply: Otto Fowler  
Date: November 11, 2022 at 15:10:06
To: dev@plc4x.apache.org 
, Christofer
Dutz  
Subject:  Re: [DISCUSS] Rename Fields -> Tags?

Sorry, I thought the name change would change the API, thus a major release.




From: Christofer Dutz 

Reply: dev@plc4x.apache.org  
Date: November 10, 2022 at 08:15:55
To: dev@plc4x.apache.org  
Subject:  Re: [DISCUSS] Rename Fields -> Tags?

Hi Otto,

I guess we should probably release at least one version with the minor
versioning scheme in order to get some feedback on if this works for all …
don’t want to end at 19.0.0 too soon, because we keep on adding breaking
changes 

But in general, yes I think that we should consider a 1.0.0 for 2023


Chris

From: Otto Fowler 
Date: Thursday, 10. November 2022 at 13:48
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Rename Fields -> Tags?
So the next release will be a major one?

From: Christofer Dutz 

Reply: dev@plc4x.apache.org  
Date: November 9, 2022 at 13:45:45
To: dev@plc4x.apache.org  
Subject: Re: [DISCUSS] Rename Fields -> Tags?

Hi All,

thanks for that.
And just an update … I’m already working hard on this on my refactoring
banch.
Reason was, that I only wanted to break SNAPSHOT once for anyone that might
be relying on it.

Chris

From: Xiangdong Huang 
Date: Wednesday, 9. November 2022 at 05:11
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Rename Fields -> Tags?
+1 for Tag.

Just want to share that I researched many historian systems (include
OSIsoft PI, Siemens WinCC, Emerson DeltaV, etc.), all of them are
using "Tag".

---
Xiangdong Huang
School of Software, Tsinghua University

黄向东
清华大学 软件学院

Otto Fowler  于2022年11月9日周三 11:41写道：
>
> +1
>
> From: Ben Hutcheson  
> Reply: dev@plc4x.apache.org  
> Date: November 8, 2022 at 15:20:51
> To: dev@plc4x.apache.org  
> Subject: Re: [DISCUSS] Rename Fields -> Tags?
>
> +1, while I don't have your commitment to go around and change it. I
think
> it makes it better aligned with OT nomenclature.
>
> On Tue, Nov 8, 2022 at 2:21 AM Christofer Dutz 


> wrote:
>
> > Hmmm … ok,
> >
> > So, I count two people for using Tag and sort of Two for using Field.
> > Am I correct with this?
> >
> > At least my LinkedIn question seems to be clear that most people would
be
> > expecting “Tag”.
> > And I mean … I think we don’t need to work on having PLC4X accepted on
> the
> > IT side, but on the OT side.
> > Making it more aligned with what the OT folks expect seems to be a
better
> > path for me.
> >
> > But I would really appreciate a bit more clear outcome of this
> discussion…
> > so anyone who’s not posted his opinion yet is highly encouraged to do
so.
> >
> > I’d just hate to rename something like that after a 1.0.0.
> >
> > Chris
> >
> >
> >
> > From: jl hong 
> > Date: Tuesday, 8. November 2022 at 02:56
> > To: dev@plc4x.apache.org 
> > Subject: Re: [DISCUSS] Rename Fields -> Tags?
> > Hello Chris,
> > I had the same confusion with Łukasz about what "Tag" meant when I
first
> > met it in using Rockwell
> > PLCs.Maybe it is more difficult to understand than "Field".Also, I
think
> > "Field" is not accurate enough too.
> > Finally, I think either "Tag" or "Field" is acceptable, and people
should
> > both be able to understand it from the document or context.
> > By the way, we call it "Point Position" in Chinese, I translated
> directly.
> >
> > Christofer Dutz  於 2022年11月8日 週二 凌晨4:49寫道：
> >
> > > Probably should rename „fieldQuery“ to „fieldAddress” (or tagAddress)
> as
> > I
> > > split Fields and Queries as a query usually targets more than one
> element
> > > and an address normaly doesn’t.
> > >
> > > Chris
> > >
> > > From: Christofer Dutz 
> > > Date: Monday, 7. November 2022 at 21:40
> > > To: dev@plc4x.apache.org 
> > > Subject: Re: [DISCUSS] Rename Fields -> Tags?
> > > And regarding your points, Lukasz,
> > >
> > > The output from the Browse API is that it is a BrowseItem. This
> contains
> > a
> > > Field (or Tag if we rename it) and loads of metadata.
> > > Is the Field readable, writable, subscribable, loads of protocol
> > dependent
> > > options.
> > >
> > > The Field itself now should be able to produce an address string that
> > > should be able to re-produce it. The APIs all support “addFieldQuery”
> > which
> > > takes this string representation or “addField” which directly
receives
> > the
> > > field object.
> > >
> > > Chris
> > >
> > >
> > > From: Łukasz Dywicki 
> > > Date: Monday, 7. November 2022 at 13:48
> > > To: dev@plc4x.apache.org 
> > > Subject: Re: [DISCUSS] Rename Fields -> Tags?
> > > Hey Chris,
> > > I do not insist on any side. Knowing how hard it is to get a "common
> > > understanding" on certain things I think it is easier if we stick
with
> > > project specific concept.
> > >
> > > Other point, we do not need to re-use a PlcField and field notion
> > > everywhere. For example output from browse api might be a descriptor
> > > which 

Re: [DISCUSS] Rename Fields -> Tags?

[Otto Fowler]

Sorry, I thought the name change would change the API, thus a major release.




From: Christofer Dutz 

Reply: dev@plc4x.apache.org  
Date: November 10, 2022 at 08:15:55
To: dev@plc4x.apache.org  
Subject:  Re: [DISCUSS] Rename Fields -> Tags?

Hi Otto,

I guess we should probably release at least one version with the minor
versioning scheme in order to get some feedback on if this works for all …
don’t want to end at 19.0.0 too soon, because we keep on adding breaking
changes 

But in general, yes I think that we should consider a 1.0.0 for 2023


Chris

From: Otto Fowler 
Date: Thursday, 10. November 2022 at 13:48
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Rename Fields -> Tags?
So the next release will be a major one?

From: Christofer Dutz 

Reply: dev@plc4x.apache.org  
Date: November 9, 2022 at 13:45:45
To: dev@plc4x.apache.org  
Subject: Re: [DISCUSS] Rename Fields -> Tags?

Hi All,

thanks for that.
And just an update … I’m already working hard on this on my refactoring
banch.
Reason was, that I only wanted to break SNAPSHOT once for anyone that might
be relying on it.

Chris

From: Xiangdong Huang 
Date: Wednesday, 9. November 2022 at 05:11
To: dev@plc4x.apache.org 
Subject: Re: [DISCUSS] Rename Fields -> Tags?
+1 for Tag.

Just want to share that I researched many historian systems (include
OSIsoft PI, Siemens WinCC, Emerson DeltaV, etc.), all of them are
using "Tag".

---
Xiangdong Huang
School of Software, Tsinghua University

黄向东
清华大学 软件学院

Otto Fowler  于2022年11月9日周三 11:41写道：
>
> +1
>
> From: Ben Hutcheson  
> Reply: dev@plc4x.apache.org  
> Date: November 8, 2022 at 15:20:51
> To: dev@plc4x.apache.org  
> Subject: Re: [DISCUSS] Rename Fields -> Tags?
>
> +1, while I don't have your commitment to go around and change it. I
think
> it makes it better aligned with OT nomenclature.
>
> On Tue, Nov 8, 2022 at 2:21 AM Christofer Dutz 


> wrote:
>
> > Hmmm … ok,
> >
> > So, I count two people for using Tag and sort of Two for using Field.
> > Am I correct with this?
> >
> > At least my LinkedIn question seems to be clear that most people would
be
> > expecting “Tag”.
> > And I mean … I think we don’t need to work on having PLC4X accepted on
> the
> > IT side, but on the OT side.
> > Making it more aligned with what the OT folks expect seems to be a
better
> > path for me.
> >
> > But I would really appreciate a bit more clear outcome of this
> discussion…
> > so anyone who’s not posted his opinion yet is highly encouraged to do
so.
> >
> > I’d just hate to rename something like that after a 1.0.0.
> >
> > Chris
> >
> >
> >
> > From: jl hong 
> > Date: Tuesday, 8. November 2022 at 02:56
> > To: dev@plc4x.apache.org 
> > Subject: Re: [DISCUSS] Rename Fields -> Tags?
> > Hello Chris,
> > I had the same confusion with Łukasz about what "Tag" meant when I
first
> > met it in using Rockwell
> > PLCs.Maybe it is more difficult to understand than "Field".Also, I
think
> > "Field" is not accurate enough too.
> > Finally, I think either "Tag" or "Field" is acceptable, and people
should
> > both be able to understand it from the document or context.
> > By the way, we call it "Point Position" in Chinese, I translated
> directly.
> >
> > Christofer Dutz  於 2022年11月8日 週二 凌晨4:49寫道：
> >
> > > Probably should rename „fieldQuery“ to „fieldAddress” (or tagAddress)
> as
> > I
> > > split Fields and Queries as a query usually targets more than one
> element
> > > and an address normaly doesn’t.
> > >
> > > Chris
> > >
> > > From: Christofer Dutz 
> > > Date: Monday, 7. November 2022 at 21:40
> > > To: dev@plc4x.apache.org 
> > > Subject: Re: [DISCUSS] Rename Fields -> Tags?
> > > And regarding your points, Lukasz,
> > >
> > > The output from the Browse API is that it is a BrowseItem. This
> contains
> > a
> > > Field (or Tag if we rename it) and loads of metadata.
> > > Is the Field readable, writable, subscribable, loads of protocol
> > dependent
> > > options.
> > >
> > > The Field itself now should be able to produce an address string that
> > > should be able to re-produce it. The APIs all support “addFieldQuery”
> > which
> > > takes this string representation or “addField” which directly
receives
> > the
> > > field object.
> > >
> > > Chris
> > >
> > >
> > > From: Łukasz Dywicki 
> > > Date: Monday, 7. November 2022 at 13:48
> > > To: dev@plc4x.apache.org 
> > > Subject: Re: [DISCUSS] Rename Fields -> Tags?
> > > Hey Chris,
> > > I do not insist on any side. Knowing how hard it is to get a "common
> > > understanding" on certain things I think it is easier if we stick
with
> > > project specific concept.
> > >
> > > Other point, we do not need to re-use a PlcField and field notion
> > > everywhere. For example output from browse api might be a descriptor
> > > which can be used to construct a field address. After all, a browsing
> > > functionality might provide more information than needed to fetch
data
> -
> > > ie. human readable name, description or other elements 

[GitHub] [plc4x] dependabot[bot] commented on pull request #563: build(deps): bump maven-shade-plugin from 3.2.4 to 3.4.1

[GitBox]

dependabot[bot] commented on PR #563:
URL: https://github.com/apache/plc4x/pull/563#issuecomment-1311978135

   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. If you'd rather skip all updates until the next 
major or minor version, let me know by commenting `@dependabot ignore this 
major version` or `@dependabot ignore this minor version`. You can also ignore 
all major, minor, or patch releases for a dependency by adding an [`ignore` 
condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore)
 with the desired `update_types` to your config file.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
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: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [plc4x] sruehl closed pull request #563: build(deps): bump maven-shade-plugin from 3.2.4 to 3.4.1

[GitBox]

sruehl closed pull request #563: build(deps): bump maven-shade-plugin from 
3.2.4 to 3.4.1
URL: https://github.com/apache/plc4x/pull/563


-- 
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: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [plc4x] sruehl merged pull request #579: build(deps): bump kotlin.version from 1.7.20 to 1.7.21

[GitBox]

sruehl merged PR #579:
URL: https://github.com/apache/plc4x/pull/579


-- 
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: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [plc4x] sruehl merged pull request #650: build(deps): bump netty-bom from 4.1.84.Final to 4.1.85.Final

[GitBox]

sruehl merged PR #650:
URL: https://github.com/apache/plc4x/pull/650


-- 
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: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [plc4x] sruehl merged pull request #651: build(deps): bump golang.org/x/tools from 0.2.0 to 0.3.0 in /plc4go

[GitBox]

sruehl merged PR #651:
URL: https://github.com/apache/plc4x/pull/651


-- 
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: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[PLC4GO] S7: reading WORD array

[Willem Remie]

Hi all,

First of all, thank you so much for all the effort which went into the project 
so far. It is a very promising project to break open the industrial arena for a 
lot of use-cases.

I’ve used the hello_world_plc4go_read.go example as a template to communicate 
with an S7-314-2 PN/DP controller. Reading a single WORD tag works perfectly 
fine using following "%DB1:0:WORD" string. However, when trying to read an 
array of WORDS using the length parameter "%DB1:0:WORD[8]" it always returns 
the first WORD.

As I’m new to the project I’m not sure if reading an array requires a different 
ReadRequest or it should work with minimal adjustments of the example. I’m in 
doubt because I see some issues on gitlab/jira with problems reading/writing 
(large) arrays.

Regards,
Willem Remie

Re: [PLC4PY] Required setup for building?

[Lukas Ott]

yes leave it at 3.7.

They are currently improving a lot - 3.10 was a major shift and 3.11 has
lot of neat improvements concerning error handling.
See also: Built-in Exceptions — Python 3.11.0 documentation
 and Python 3.11
Preview: Even Better Error Messages – Real Python


So yes when Plc4Py gets actually usable we can bump it to a stable 3.XX
version.




Am Fr., 11. Nov. 2022 um 12:08 Uhr schrieb Ben Hutcheson <
ben.hut...@gmail.com>:

> No, just leave the prerequisite check, 3.7 is still a reasonable starting
> point (Although by the time Plc4Py actually gets useable it probably won't
> be)
>
> On Fri, Nov 11, 2022 at 5:03 AM Christofer Dutz  >
> wrote:
>
> > Oh …
> >
> > if it’s just that, I can simply add that to the prerequisite check.
> > That currently checks, if python is at least 3.7.0, I can bump that to
> > 3.10.0 … however it seems that 3.9 is simpler to setup (As I didn’t
> > explicitly select a version and that one was installed). So if the
> benefit
> > of 3.10+ is not too big, perhaps make it work with 3.9.x.
> >
> > Chris
> >
> >
> > From: Ben Hutcheson 
> > Date: Friday, 11. November 2022 at 11:55
> > To: dev@plc4x.apache.org 
> > Subject: Re: [PLC4PY] Required setup for building?
> > Hi,
> >
> > Yeah it looks like we'll have to work on support for Python version <
> 3.10.
> > It should be an easy fix to use the Union operator for type hints instead
> > of the Pipe symbol.
> >
> > Ben
> >
> > On Fri, Nov 11, 2022 at 4:50 AM Christofer Dutz <
> christofer.d...@c-ware.de
> > >
> > wrote:
> >
> > > [INFO] --- exec-maven-plugin:3.1.0:exec (python-test) @ plc4py ---
> > > = test session starts
> > > ==
> > > platform darwin -- Python 3.9.12, pytest-7.2.0, pluggy-1.0.0 --
> > >
> >
> /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py/venv/bin/python3
> > > cachedir: .pytest_cache
> > > rootdir:
> > /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py,
> > > configfile: setup.cfg
> > > plugins: mock-3.10.0, asyncio-0.20.1
> > > asyncio: mode=auto
> > > collecting ... collected 16 items / 2 errors
> > >
> > >  ERRORS
> > > 
> > >  ERROR collecting tests/test_plc4py.py
> > > _
> > > tests/test_plc4py.py:28: in 
> > > from plc4py.drivers.modbus.ModbusConnection import ModbusConnection
> > > plc4py/drivers/modbus/ModbusConnection.py:30: in 
> > > from plc4py.drivers.modbus.ModbusProtocol import ModbusProtocol
> > > plc4py/drivers/modbus/ModbusProtocol.py:21: in 
> > > from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> > > plc4py/spi/Plc4xBaseProtocol.py:25: in 
> > > class Plc4xBaseProtocol(Protocol):
> > > plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> > > def connection_lost(self, exc: Exception | None) -> None:
> > > E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> > > ___ ERROR collecting tests/unit/plc4py/spi/test_protocol.py
> > > 
> > > tests/unit/plc4py/spi/test_protocol.py:26: in 
> > > from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> > > plc4py/spi/Plc4xBaseProtocol.py:25: in 
> > > class Plc4xBaseProtocol(Protocol):
> > > plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> > > def connection_lost(self, exc: Exception | None) -> None:
> > > E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> > > === short test summary info
> > > 
> > > ERROR tests/test_plc4py.py - TypeError: unsupported operand type(s) for
> > |:
> > > 't...
> > > ERROR tests/unit/plc4py/spi/test_protocol.py - TypeError: unsupported
> > > operand...
> > > !!! Interrupted: 2 errors during collection
> > > 
> > > == 2 errors in 0.08s
> > > ===
> > > [ERROR] Command execution failed.
> > > org.apache.commons.exec.ExecuteException: Process exited with an
> error: 2
> > > (Exit value: 2)
> > > at org.apache.commons.exec.DefaultExecutor.executeInternal
> > > (DefaultExecutor.java:404)
> > > at org.apache.commons.exec.DefaultExecutor.execute
> > > (DefaultExecutor.java:166)
> > > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> > > (ExecMojo.java:1000)
> > > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> > > (ExecMojo.java:947)
> > > at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
> > > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> > > (DefaultBuildPluginManager.java:137)
> > > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > > (MojoExecutor.java:210)
> > > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > > (MojoExecutor.java:156)
> > > at 

Re: [PLC4PY] Required setup for building?

[Ben Hutcheson]

No, just leave the prerequisite check, 3.7 is still a reasonable starting
point (Although by the time Plc4Py actually gets useable it probably won't
be)

On Fri, Nov 11, 2022 at 5:03 AM Christofer Dutz 
wrote:

> Oh …
>
> if it’s just that, I can simply add that to the prerequisite check.
> That currently checks, if python is at least 3.7.0, I can bump that to
> 3.10.0 … however it seems that 3.9 is simpler to setup (As I didn’t
> explicitly select a version and that one was installed). So if the benefit
> of 3.10+ is not too big, perhaps make it work with 3.9.x.
>
> Chris
>
>
> From: Ben Hutcheson 
> Date: Friday, 11. November 2022 at 11:55
> To: dev@plc4x.apache.org 
> Subject: Re: [PLC4PY] Required setup for building?
> Hi,
>
> Yeah it looks like we'll have to work on support for Python version < 3.10.
> It should be an easy fix to use the Union operator for type hints instead
> of the Pipe symbol.
>
> Ben
>
> On Fri, Nov 11, 2022 at 4:50 AM Christofer Dutz  >
> wrote:
>
> > [INFO] --- exec-maven-plugin:3.1.0:exec (python-test) @ plc4py ---
> > = test session starts
> > ==
> > platform darwin -- Python 3.9.12, pytest-7.2.0, pluggy-1.0.0 --
> >
> /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py/venv/bin/python3
> > cachedir: .pytest_cache
> > rootdir:
> /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py,
> > configfile: setup.cfg
> > plugins: mock-3.10.0, asyncio-0.20.1
> > asyncio: mode=auto
> > collecting ... collected 16 items / 2 errors
> >
> >  ERRORS
> > 
> >  ERROR collecting tests/test_plc4py.py
> > _
> > tests/test_plc4py.py:28: in 
> > from plc4py.drivers.modbus.ModbusConnection import ModbusConnection
> > plc4py/drivers/modbus/ModbusConnection.py:30: in 
> > from plc4py.drivers.modbus.ModbusProtocol import ModbusProtocol
> > plc4py/drivers/modbus/ModbusProtocol.py:21: in 
> > from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> > plc4py/spi/Plc4xBaseProtocol.py:25: in 
> > class Plc4xBaseProtocol(Protocol):
> > plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> > def connection_lost(self, exc: Exception | None) -> None:
> > E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> > ___ ERROR collecting tests/unit/plc4py/spi/test_protocol.py
> > 
> > tests/unit/plc4py/spi/test_protocol.py:26: in 
> > from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> > plc4py/spi/Plc4xBaseProtocol.py:25: in 
> > class Plc4xBaseProtocol(Protocol):
> > plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> > def connection_lost(self, exc: Exception | None) -> None:
> > E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> > === short test summary info
> > 
> > ERROR tests/test_plc4py.py - TypeError: unsupported operand type(s) for
> |:
> > 't...
> > ERROR tests/unit/plc4py/spi/test_protocol.py - TypeError: unsupported
> > operand...
> > !!! Interrupted: 2 errors during collection
> > 
> > == 2 errors in 0.08s
> > ===
> > [ERROR] Command execution failed.
> > org.apache.commons.exec.ExecuteException: Process exited with an error: 2
> > (Exit value: 2)
> > at org.apache.commons.exec.DefaultExecutor.executeInternal
> > (DefaultExecutor.java:404)
> > at org.apache.commons.exec.DefaultExecutor.execute
> > (DefaultExecutor.java:166)
> > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> > (ExecMojo.java:1000)
> > at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> > (ExecMojo.java:947)
> > at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
> > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> > (DefaultBuildPluginManager.java:137)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:210)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:156)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:148)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > (LifecycleModuleBuilder.java:117)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > (LifecycleModuleBuilder.java:81)
> > at
> >
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> > (SingleThreadedBuilder.java:56)
> > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> > (LifecycleStarter.java:128)
> > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> > at org.apache.maven.DefaultMaven.execute 

Re: [PLC4PY] Required setup for building?

[Christofer Dutz]

Oh …

if it’s just that, I can simply add that to the prerequisite check.
That currently checks, if python is at least 3.7.0, I can bump that to 3.10.0 … 
however it seems that 3.9 is simpler to setup (As I didn’t explicitly select a 
version and that one was installed). So if the benefit of 3.10+ is not too big, 
perhaps make it work with 3.9.x.

Chris


From: Ben Hutcheson 
Date: Friday, 11. November 2022 at 11:55
To: dev@plc4x.apache.org 
Subject: Re: [PLC4PY] Required setup for building?
Hi,

Yeah it looks like we'll have to work on support for Python version < 3.10.
It should be an easy fix to use the Union operator for type hints instead
of the Pipe symbol.

Ben

On Fri, Nov 11, 2022 at 4:50 AM Christofer Dutz 
wrote:

> [INFO] --- exec-maven-plugin:3.1.0:exec (python-test) @ plc4py ---
> = test session starts
> ==
> platform darwin -- Python 3.9.12, pytest-7.2.0, pluggy-1.0.0 --
> /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py/venv/bin/python3
> cachedir: .pytest_cache
> rootdir: /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py,
> configfile: setup.cfg
> plugins: mock-3.10.0, asyncio-0.20.1
> asyncio: mode=auto
> collecting ... collected 16 items / 2 errors
>
>  ERRORS
> 
>  ERROR collecting tests/test_plc4py.py
> _
> tests/test_plc4py.py:28: in 
> from plc4py.drivers.modbus.ModbusConnection import ModbusConnection
> plc4py/drivers/modbus/ModbusConnection.py:30: in 
> from plc4py.drivers.modbus.ModbusProtocol import ModbusProtocol
> plc4py/drivers/modbus/ModbusProtocol.py:21: in 
> from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> plc4py/spi/Plc4xBaseProtocol.py:25: in 
> class Plc4xBaseProtocol(Protocol):
> plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> def connection_lost(self, exc: Exception | None) -> None:
> E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> ___ ERROR collecting tests/unit/plc4py/spi/test_protocol.py
> 
> tests/unit/plc4py/spi/test_protocol.py:26: in 
> from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> plc4py/spi/Plc4xBaseProtocol.py:25: in 
> class Plc4xBaseProtocol(Protocol):
> plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> def connection_lost(self, exc: Exception | None) -> None:
> E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> === short test summary info
> 
> ERROR tests/test_plc4py.py - TypeError: unsupported operand type(s) for |:
> 't...
> ERROR tests/unit/plc4py/spi/test_protocol.py - TypeError: unsupported
> operand...
> !!! Interrupted: 2 errors during collection
> 
> == 2 errors in 0.08s
> ===
> [ERROR] Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 2
> (Exit value: 2)
> at org.apache.commons.exec.DefaultExecutor.executeInternal
> (DefaultExecutor.java:404)
> at org.apache.commons.exec.DefaultExecutor.execute
> (DefaultExecutor.java:166)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> (ExecMojo.java:1000)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> (ExecMojo.java:947)
> at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:104)
> at java.lang.reflect.Method.invoke (Method.java:577)
> at 

Re: [PLC4PY] Required setup for building?

[Ben Hutcheson]

Just pushed a change, I've also removed the manual tests

On Fri, Nov 11, 2022 at 4:55 AM Ben Hutcheson  wrote:

> Hi,
>
> Yeah it looks like we'll have to work on support for Python version <
> 3.10. It should be an easy fix to use the Union operator for type hints
> instead of the Pipe symbol.
>
> Ben
>
> On Fri, Nov 11, 2022 at 4:50 AM Christofer Dutz 
> wrote:
>
>> [INFO] --- exec-maven-plugin:3.1.0:exec (python-test) @ plc4py ---
>> = test session starts
>> ==
>> platform darwin -- Python 3.9.12, pytest-7.2.0, pluggy-1.0.0 --
>> /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py/venv/bin/python3
>> cachedir: .pytest_cache
>> rootdir:
>> /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py,
>> configfile: setup.cfg
>> plugins: mock-3.10.0, asyncio-0.20.1
>> asyncio: mode=auto
>> collecting ... collected 16 items / 2 errors
>>
>>  ERRORS
>> 
>>  ERROR collecting tests/test_plc4py.py
>> _
>> tests/test_plc4py.py:28: in 
>> from plc4py.drivers.modbus.ModbusConnection import ModbusConnection
>> plc4py/drivers/modbus/ModbusConnection.py:30: in 
>> from plc4py.drivers.modbus.ModbusProtocol import ModbusProtocol
>> plc4py/drivers/modbus/ModbusProtocol.py:21: in 
>> from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
>> plc4py/spi/Plc4xBaseProtocol.py:25: in 
>> class Plc4xBaseProtocol(Protocol):
>> plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
>> def connection_lost(self, exc: Exception | None) -> None:
>> E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
>> ___ ERROR collecting tests/unit/plc4py/spi/test_protocol.py
>> 
>> tests/unit/plc4py/spi/test_protocol.py:26: in 
>> from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
>> plc4py/spi/Plc4xBaseProtocol.py:25: in 
>> class Plc4xBaseProtocol(Protocol):
>> plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
>> def connection_lost(self, exc: Exception | None) -> None:
>> E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
>> === short test summary info
>> 
>> ERROR tests/test_plc4py.py - TypeError: unsupported operand type(s) for
>> |: 't...
>> ERROR tests/unit/plc4py/spi/test_protocol.py - TypeError: unsupported
>> operand...
>> !!! Interrupted: 2 errors during collection
>> 
>> == 2 errors in 0.08s
>> ===
>> [ERROR] Command execution failed.
>> org.apache.commons.exec.ExecuteException: Process exited with an error: 2
>> (Exit value: 2)
>> at org.apache.commons.exec.DefaultExecutor.executeInternal
>> (DefaultExecutor.java:404)
>> at org.apache.commons.exec.DefaultExecutor.execute
>> (DefaultExecutor.java:166)
>> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
>> (ExecMojo.java:1000)
>> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
>> (ExecMojo.java:947)
>> at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
>> (DefaultBuildPluginManager.java:137)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
>> (MojoExecutor.java:210)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
>> (MojoExecutor.java:156)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
>> (MojoExecutor.java:148)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
>> (LifecycleModuleBuilder.java:117)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
>> (LifecycleModuleBuilder.java:81)
>> at
>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>> (SingleThreadedBuilder.java:56)
>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
>> (LifecycleStarter.java:128)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
>> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
>> (DirectMethodHandleAccessor.java:104)
>> at java.lang.reflect.Method.invoke (Method.java:577)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
>> (Launcher.java:282)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
>> (Launcher.java:225)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
>> (Launcher.java:406)
>> at 

Re: [PLC4PY] Required setup for building?

[Ben Hutcheson]

Hi,

Yeah it looks like we'll have to work on support for Python version < 3.10.
It should be an easy fix to use the Union operator for type hints instead
of the Pipe symbol.

Ben

On Fri, Nov 11, 2022 at 4:50 AM Christofer Dutz 
wrote:

> [INFO] --- exec-maven-plugin:3.1.0:exec (python-test) @ plc4py ---
> = test session starts
> ==
> platform darwin -- Python 3.9.12, pytest-7.2.0, pluggy-1.0.0 --
> /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py/venv/bin/python3
> cachedir: .pytest_cache
> rootdir: /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py,
> configfile: setup.cfg
> plugins: mock-3.10.0, asyncio-0.20.1
> asyncio: mode=auto
> collecting ... collected 16 items / 2 errors
>
>  ERRORS
> 
>  ERROR collecting tests/test_plc4py.py
> _
> tests/test_plc4py.py:28: in 
> from plc4py.drivers.modbus.ModbusConnection import ModbusConnection
> plc4py/drivers/modbus/ModbusConnection.py:30: in 
> from plc4py.drivers.modbus.ModbusProtocol import ModbusProtocol
> plc4py/drivers/modbus/ModbusProtocol.py:21: in 
> from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> plc4py/spi/Plc4xBaseProtocol.py:25: in 
> class Plc4xBaseProtocol(Protocol):
> plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> def connection_lost(self, exc: Exception | None) -> None:
> E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> ___ ERROR collecting tests/unit/plc4py/spi/test_protocol.py
> 
> tests/unit/plc4py/spi/test_protocol.py:26: in 
> from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
> plc4py/spi/Plc4xBaseProtocol.py:25: in 
> class Plc4xBaseProtocol(Protocol):
> plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
> def connection_lost(self, exc: Exception | None) -> None:
> E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
> === short test summary info
> 
> ERROR tests/test_plc4py.py - TypeError: unsupported operand type(s) for |:
> 't...
> ERROR tests/unit/plc4py/spi/test_protocol.py - TypeError: unsupported
> operand...
> !!! Interrupted: 2 errors during collection
> 
> == 2 errors in 0.08s
> ===
> [ERROR] Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 2
> (Exit value: 2)
> at org.apache.commons.exec.DefaultExecutor.executeInternal
> (DefaultExecutor.java:404)
> at org.apache.commons.exec.DefaultExecutor.execute
> (DefaultExecutor.java:166)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> (ExecMojo.java:1000)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
> (ExecMojo.java:947)
> at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:104)
> at java.lang.reflect.Method.invoke (Method.java:577)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
> [INFO]
> 
> [INFO] BUILD FAILURE
> 

Re: [PLC4PY] Required setup for building?

[Christofer Dutz]

[INFO] --- exec-maven-plugin:3.1.0:exec (python-test) @ plc4py ---
= test session starts ==
platform darwin -- Python 3.9.12, pytest-7.2.0, pluggy-1.0.0 -- 
/Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py/venv/bin/python3
cachedir: .pytest_cache
rootdir: /Users/christoferdutz/Projects/Apache/PLC4X/plc4x/sandbox/plc4py, 
configfile: setup.cfg
plugins: mock-3.10.0, asyncio-0.20.1
asyncio: mode=auto
collecting ... collected 16 items / 2 errors

 ERRORS 
 ERROR collecting tests/test_plc4py.py _
tests/test_plc4py.py:28: in 
from plc4py.drivers.modbus.ModbusConnection import ModbusConnection
plc4py/drivers/modbus/ModbusConnection.py:30: in 
from plc4py.drivers.modbus.ModbusProtocol import ModbusProtocol
plc4py/drivers/modbus/ModbusProtocol.py:21: in 
from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
plc4py/spi/Plc4xBaseProtocol.py:25: in 
class Plc4xBaseProtocol(Protocol):
plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
def connection_lost(self, exc: Exception | None) -> None:
E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
___ ERROR collecting tests/unit/plc4py/spi/test_protocol.py 
tests/unit/plc4py/spi/test_protocol.py:26: in 
from plc4py.spi.Plc4xBaseProtocol import Plc4xBaseProtocol
plc4py/spi/Plc4xBaseProtocol.py:25: in 
class Plc4xBaseProtocol(Protocol):
plc4py/spi/Plc4xBaseProtocol.py:35: in Plc4xBaseProtocol
def connection_lost(self, exc: Exception | None) -> None:
E   TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'
=== short test summary info 
ERROR tests/test_plc4py.py - TypeError: unsupported operand type(s) for |: 't...
ERROR tests/unit/plc4py/spi/test_protocol.py - TypeError: unsupported operand...
!!! Interrupted: 2 errors during collection 
== 2 errors in 0.08s ===
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 2 (Exit 
value: 2)
at org.apache.commons.exec.DefaultExecutor.executeInternal 
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute 
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:947)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke 
(DirectMethodHandleAccessor.java:104)
at java.lang.reflect.Method.invoke (Method.java:577)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:347)
at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  11.937 s
[INFO] Finished at: 2022-11-11T11:49:37+01:00
[INFO] 

From: Ben Hutcheson 
Date: Friday, 11. November 2022 at 11:46
To: dev@plc4x.apache.org 
Subject: Re: [PLC4PY] Required setup for building?
Hi Chris,

I'm not sure much has changed 

Re: [PLC4PY] Required setup for building?

[Ben Hutcheson]

Hi Chris,

I'm not sure much has changed since last time, can you send me the output
you're seeing?

Ben

On Fri, Nov 11, 2022 at 4:07 AM Christofer Dutz 
wrote:

> Hi all,
>
> some time ago I added some checks to the prerequisite check to ensure I’m
> able to build PLC4PY before even trying. For some time now this has been
> failing on my side, so I guess there are some changes there.
>
> Could someone please help me adjust the prerequisite check to work for
> PLC4Py again?
>
> Chris
>
>

[PLC4PY] Required setup for building?

[Christofer Dutz]

Hi all,

some time ago I added some checks to the prerequisite check to ensure I’m able 
to build PLC4PY before even trying. For some time now this has been failing on 
my side, so I guess there are some changes there.

Could someone please help me adjust the prerequisite check to work for PLC4Py 
again?

Chris