AW: [Python] Adding build support for Python
Hi Chris,
Cool stuff.. So go on you pythoneers.. As I remember Matthias, Bjorn and
dhoomateku should be. Or?
Julian
Von meinem Mobiltelefon gesendet
Ursprüngliche Nachricht
Betreff: Re: [Python] Adding build support for Python
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
Ok ... so I tried this out and it worked.
I just committed a setup.py 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 setup.py
stuff cool :-)
Also would it be cool, if it could do its work in the target directory as all
other modules do it.
Chris
Am 30.04.19, 22:33 schrieb "Julian Feinauer" :
Haha, python really went into your head.
I agree with your suggestion, that sounds reasonable.
J
Von meinem Mobiltelefon gesendet
Ursprüngliche Nachricht
Betreff: Re: [Python] Adding build support for Python
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
I just had another idea ...
The setup.py 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.
Chris
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.
Julian
Von meinem Mobiltelefon gesendet
Ursprüngliche Nachricht
Betreff: Re: [Python] Adding build support for Python
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
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 setup.py in there that uses ${} for stuff injected from the
pom and to use the resource-plugin with enabled filtering to generate a usable
setup.py in the target directory, yes.
@Björn
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.
Chris
Am 30.04.19, 16:30 schrieb "Julian Feinauer"
:
Hi,
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?
Julian
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 part.
So in the python world it seems as if usually a setup.py 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 setup.py (by including data from
maven to that file) and then run “python setup.py install” which then generates
everything
* Write a setup.py (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 anothe
AW: [Python] Adding build support for Python
Haha, python really went into your head.
I agree with your suggestion, that sounds reasonable.
J
Von meinem Mobiltelefon gesendet
Ursprüngliche Nachricht
Betreff: Re: [Python] Adding build support for Python
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
I just had another idea ...
The setup.py 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.
Chris
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.
Julian
Von meinem Mobiltelefon gesendet
Ursprüngliche Nachricht
Betreff: Re: [Python] Adding build support for Python
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
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 setup.py in there that uses ${} for stuff injected from the pom and to
use the resource-plugin with enabled filtering to generate a usable setup.py in
the target directory, yes.
@Björn
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.
Chris
Am 30.04.19, 16:30 schrieb "Julian Feinauer" :
Hi,
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?
Julian
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 part.
So in the python world it seems as if usually a setup.py 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 setup.py (by including data from maven
to that file) and then run “python setup.py install” which then generates
everything
* Write a setup.py (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?
Chris
AW: [Python] Adding build support for Python
Hi Chris,
Sorry for that. I just meant -1, so I agree with your resume.
But yes +1 for 2.
Julian
Von meinem Mobiltelefon gesendet
Ursprüngliche Nachricht
Betreff: Re: [Python] Adding build support for Python
Von: Christofer Dutz
An: dev@plc4x.apache.org
Cc:
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 setup.py in there that uses ${} for stuff injected from the pom and to
use the resource-plugin with enabled filtering to generate a usable setup.py in
the target directory, yes.
@Björn
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.
Chris
Am 30.04.19, 16:30 schrieb "Julian Feinauer" :
Hi,
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?
Julian
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 part.
So in the python world it seems as if usually a setup.py 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 setup.py (by including data from maven to
that file) and then run “python setup.py install” which then generates
everything
* Write a setup.py (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?
Chris
AW: [Python] Adding build support for Python
Hey Chris, as far as I am informed the more modern standard for distribution in Python is python wheels. Which already contains the precompiled sources for the platforms in case of C extensions and is more or less a plain ZIP for pure Python (https://pypi.org/project/wheel/). The mechanisms for building though are more or less the same as with eggs. I personally would prefer the 2nd option even if it is slightly more uncomfortable for Python users but we avoid confusion with versions and other stuff. Björn -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 30. April 2019 16:04 An: dev@plc4x.apache.org Betreff: [Python] Adding build support for Python Hi all, After streamlining the build for C++ I now started to have a look at the Python part. So in the python world it seems as if usually a setup.py 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 setup.py (by including data from maven to that file) and then run “python setup.py install” which then generates everything * Write a setup.py (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? Chris
