plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Feinauer <>
Subject AW: [Python] Adding build support for Python
Date Wed, 01 May 2019 09:41:57 GMT
Hi Chris,

Cool stuff..  So go on you pythoneers..  As I remember Matthias, Bjorn and dhoomateku should
be. Or?


Von meinem Mobiltelefon gesendet

-------- Ursprüngliche Nachricht --------
Betreff: Re: [Python] Adding build support for Python
Von: Christofer Dutz

Ok ... so I tried this out and it worked.

I just committed a script (probably a bad one) but the point is, I made it read the
pom.xml and get artifactId, version and description from that and it worked.
Would be super cool, if someone with python knowledge could make the stuff cool :-)
Also would it be cool, if it could do its work in the target directory as all other modules
do it.


Am 30.04.19, 22:33 schrieb "Julian Feinauer" <>:

    Haha, python really went into your head.
    I agree with your suggestion, that sounds reasonable.


    Von meinem Mobiltelefon gesendet

    -------- Ursprüngliche Nachricht --------
    Betreff: Re: [Python] Adding build support for Python
    Von: Christofer Dutz

    I just had another idea ...

    The is a python script that is executed.
    So couldn't I extend that script to load data from the pom in the same directory?
    After all, it's just an XML file ...

    This way we would have the benefit of good tool support for Python and no maven preparation
being needed.


    Am 30.04.19, 17:32 schrieb "Julian Feinauer" <>:

        Hi Chris,

        Sorry for that. I just meant -1, so I agree with your resume.
        But yes +1 for 2.


        Von meinem Mobiltelefon gesendet

        -------- Ursprüngliche Nachricht --------
        Betreff: Re: [Python] Adding build support for Python
        Von: Christofer Dutz

        Hi Björn and Julian,

        So Julian you are (disagreeing sort of implies I was arguing for it, which I wasn't,
I was just listing pro's and con's):
        -1 for option 1 and +1 for 2 and 3?

        Right now I would have suggested to add a "src/main/python-build" directory with a in there that uses ${} for stuff injected from the pom and to use the resource-plugin
with enabled filtering to generate a usable in the target directory, yes.

        I agree with your assessment that option 2 should be the way to go ... otherwise we
would have to do quite some hoop-jumping during the release.
        Remember the release-prepare-step: updates the version in the pom to the release version,
commits that, tags this commit and updates to the next version and also commits that ... now
we would somehow have to go back to the tagged version, update the python stuff, commit that,
change the tag, update the maven and python versions to the next and reset the head to that
... sounds ugly ;-)

        I for my part would also think option 2 would be the way to go.


        Am 30.04.19, 16:30 schrieb "Julian Feinauer" <>:


            thanks for bringing that up.
            I totally disagree with the first one, check.
            The second is okay and the third also, so I can agree with both of those.
            Do we use the resource plugin to generate it from a "template" which is human
(and IDE) readable buth with placeholders?


            Am 30.04.19, 16:04 schrieb "Christofer Dutz" <>:

                Hi all,

                After streamlining the build for C++ I now started to have a look at the Python

                So in the python world it seems as if usually a is created and then
python executes that script to build the project.
                From a look at some sample python projects, it looks as if it generally contains
some information we already have in the maven metadata.

                When executing an example build and looking at the result, it looked as if
the build generates a “egg” (Zip with ending “egg”) that contains unmodified versions
of the sources and resources. In addition the script seems to generate a “egg-info” directory
which contains a lot of different text files, these are then also included in the egg-zip.

                So I think we have multiple options here:

                  *   Have maven generate the egg-files from Maven exclusively
                  *   Have maven generate a (by including data from maven to that
file) and then run “python install” which then generates everything
                  *   Write a (duplicating data from the pom) and executing a python
build in the maven build

                The last option has the benefit of working out of the box with Python and
probably any Python IDE (If there is such a thing) but would have the drawback that we need
to manually adjust it to pom changes (Version during releases)
                The first option would eliminate the need for another build tool (but would
also eliminate the running of tests or other fancy python stuff)
                The middle option would be a compromise … it wouldn’t work out of the
box, but after running “mvnw generate-resources” it could generate the missing files and
the Python IDEs would pick it up.

                I think the middle approach sort of feels like the sweet spot at the moment
… or am I missing something here?
                Are there other options, I didn’t mention?

                What do you think?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message