* [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-04 19:00 Mark Asselstine 2017-12-16 21:58 ` Derek Straka 0 siblings, 1 reply; 33+ messages in thread From: Mark Asselstine @ 2017-12-04 19:00 UTC (permalink / raw) To: openembedded-devel Drop the json<-->simplejson patch instead opting to depend on python-json (part of core python libs). Beyond this the uprev is straightforward. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> --- .../recipes-devtools/python/python-pyroute2.inc | 23 +++++-------------- .../import-simplejson-as-json.patch | 26 ---------------------- ...yroute2_0.3.22.bb => python-pyroute2_0.4.21.bb} | 0 ...route2_0.3.22.bb => python3-pyroute2_0.4.21.bb} | 0 4 files changed, 6 insertions(+), 43 deletions(-) delete mode 100644 meta-python/recipes-devtools/python/python-pyroute2/import-simplejson-as-json.patch rename meta-python/recipes-devtools/python/{python-pyroute2_0.3.22.bb => python-pyroute2_0.4.21.bb} (100%) rename meta-python/recipes-devtools/python/{python3-pyroute2_0.3.22.bb => python3-pyroute2_0.4.21.bb} (100%) diff --git a/meta-python/recipes-devtools/python/python-pyroute2.inc b/meta-python/recipes-devtools/python/python-pyroute2.inc index da1d4cd..521162c 100644 --- a/meta-python/recipes-devtools/python/python-pyroute2.inc +++ b/meta-python/recipes-devtools/python/python-pyroute2.inc @@ -1,26 +1,15 @@ SUMMARY = "A pure Python netlink and Linux network configuration library" LICENSE = "GPLv2 & Apache-2.0" LIC_FILES_CHKSUM = "file://LICENSE.GPL.v2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ - file://LICENSE.Apache.v2;md5=3b83ef96387f14655fc854ddc3c6bd57" + file://LICENSE.Apache.v2;md5=34281e312165f843a2b7d1f114fe65ce" -SRC_URI[md5sum] = "733adb362b6603c7269c0b3df3045a55" -SRC_URI[sha256sum] = "5cdf44656cf623369f0cbf183d9d14a1a50ebdffbd50d4e30ffda62c0a05d7b3" - -SRC_URI += "file://import-simplejson-as-json.patch" +SRC_URI[md5sum] = "9c251543c4282a2f8b1a8d6aa8afc688" +SRC_URI[sha256sum] = "7afad28ee0a0f3e7c34adaa9f953d00560ed9910203e93f107833b6e8d151171" FILESEXTRAPATHS_prepend := "${THISDIR}/python-pyroute2:" inherit pypi -RDEPENDS_${PN} += "\ - ${PYTHON_PN}-distutils \ - ${PYTHON_PN}-simplejson \ - ${PYTHON_PN}-multiprocessing \ - ${PYTHON_PN}-io ${PYTHON_PN}-pprint \ - ${PYTHON_PN}-pickle \ - ${PYTHON_PN}-logging \ - ${PYTHON_PN}-threading \ - ${PYTHON_PN}-textutils \ - ${PYTHON_PN}-subprocess \ - ${PYTHON_PN}-netclient \ -" +RDEPENDS_${PN} += " \ + ${PYTHON_PN}-json \ + " diff --git a/meta-python/recipes-devtools/python/python-pyroute2/import-simplejson-as-json.patch b/meta-python/recipes-devtools/python/python-pyroute2/import-simplejson-as-json.patch deleted file mode 100644 index d73da07..0000000 --- a/meta-python/recipes-devtools/python/python-pyroute2/import-simplejson-as-json.patch +++ /dev/null @@ -1,26 +0,0 @@ -Upstream-Status: Inappropriate [wrong dependency] - -Subject: [PATCH] import simplejson as json - -At runtime python-pyroute2 tries to import json, but the module is not -available, import simplejson as json solve the issue. - -Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br> ---- - pyroute2/netlink/rtnl/ifinfmsg.py | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/pyroute2/netlink/rtnl/ifinfmsg.py b/pyroute2/netlink/rtnl/ifinfmsg.py -index 4f14f25..55643eb 100644 ---- a/pyroute2/netlink/rtnl/ifinfmsg.py -+++ b/pyroute2/netlink/rtnl/ifinfmsg.py -@@ -1,5 +1,5 @@ - import os --import json -+import simplejson as json - import errno - import select - import struct --- -2.1.4 - diff --git a/meta-python/recipes-devtools/python/python-pyroute2_0.3.22.bb b/meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb similarity index 100% rename from meta-python/recipes-devtools/python/python-pyroute2_0.3.22.bb rename to meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb diff --git a/meta-python/recipes-devtools/python/python3-pyroute2_0.3.22.bb b/meta-python/recipes-devtools/python/python3-pyroute2_0.4.21.bb similarity index 100% rename from meta-python/recipes-devtools/python/python3-pyroute2_0.3.22.bb rename to meta-python/recipes-devtools/python/python3-pyroute2_0.4.21.bb -- 2.7.4 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-04 19:00 [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) Mark Asselstine @ 2017-12-16 21:58 ` Derek Straka 2017-12-18 15:33 ` Mark Asselstine 0 siblings, 1 reply; 33+ messages in thread From: Derek Straka @ 2017-12-16 21:58 UTC (permalink / raw) To: Mark Asselstine; +Cc: openembeded-devel On Mon, Dec 4, 2017 at 2:00 PM, Mark Asselstine < mark.asselstine@windriver.com> wrote: > Drop the json<-->simplejson patch instead opting to depend on > python-json (part of core python libs). Beyond this the uprev is > straightforward. > > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> > --- > .../recipes-devtools/python/python-pyroute2.inc | 23 > +++++-------------- > .../import-simplejson-as-json.patch | 26 > ---------------------- > ...yroute2_0.3.22.bb => python-pyroute2_0.4.21.bb} | 0 > ...route2_0.3.22.bb => python3-pyroute2_0.4.21.bb} | 0 > 4 files changed, 6 insertions(+), 43 deletions(-) > delete mode 100644 meta-python/recipes-devtools/ > python/python-pyroute2/import-simplejson-as-json.patch > rename meta-python/recipes-devtools/python/{python-pyroute2_0.3.22.bb => > python-pyroute2_0.4.21.bb} (100%) > rename meta-python/recipes-devtools/python/{python3-pyroute2_0.3.22.bb > => python3-pyroute2_0.4.21.bb} (100%) > > diff --git a/meta-python/recipes-devtools/python/python-pyroute2.inc > b/meta-python/recipes-devtools/python/python-pyroute2.inc > index da1d4cd..521162c 100644 > --- a/meta-python/recipes-devtools/python/python-pyroute2.inc > +++ b/meta-python/recipes-devtools/python/python-pyroute2.inc > @@ -1,26 +1,15 @@ > SUMMARY = "A pure Python netlink and Linux network configuration library" > LICENSE = "GPLv2 & Apache-2.0" > LIC_FILES_CHKSUM = "file://LICENSE.GPL.v2;md5= > b234ee4d69f5fce4486a80fdaf4a4263 \ > - file://LICENSE.Apache.v2;md5= > 3b83ef96387f14655fc854ddc3c6bd57" > + file://LICENSE.Apache.v2;md5= > 34281e312165f843a2b7d1f114fe65ce" > > -SRC_URI[md5sum] = "733adb362b6603c7269c0b3df3045a55" > -SRC_URI[sha256sum] = "5cdf44656cf623369f0cbf183d9d14 > a1a50ebdffbd50d4e30ffda62c0a05d7b3" > - > -SRC_URI += "file://import-simplejson-as-json.patch" > +SRC_URI[md5sum] = "9c251543c4282a2f8b1a8d6aa8afc688" > +SRC_URI[sha256sum] = "7afad28ee0a0f3e7c34adaa9f953d0 > 0560ed9910203e93f107833b6e8d151171" > > Can we remove the extra path prepend now? > FILESEXTRAPATHS_prepend := "${THISDIR}/python-pyroute2:" > > inherit pypi > > -RDEPENDS_${PN} += "\ > - ${PYTHON_PN}-distutils \ > - ${PYTHON_PN}-simplejson \ > - ${PYTHON_PN}-multiprocessing \ > - ${PYTHON_PN}-io ${PYTHON_PN}-pprint \ > - ${PYTHON_PN}-pickle \ > - ${PYTHON_PN}-logging \ > - ${PYTHON_PN}-threading \ > - ${PYTHON_PN}-textutils \ > - ${PYTHON_PN}-subprocess \ > - ${PYTHON_PN}-netclient \ > -" > None of these other dependencies are needed for a minimal python install? > +RDEPENDS_${PN} += " \ > + ${PYTHON_PN}-json \ > + " > diff --git a/meta-python/recipes-devtools/python/python- > pyroute2/import-simplejson-as-json.patch b/meta-python/recipes- > devtools/python/python-pyroute2/import-simplejson-as-json.patch > deleted file mode 100644 > index d73da07..0000000 > --- a/meta-python/recipes-devtools/python/python- > pyroute2/import-simplejson-as-json.patch > +++ /dev/null > @@ -1,26 +0,0 @@ > -Upstream-Status: Inappropriate [wrong dependency] > - > -Subject: [PATCH] import simplejson as json > - > -At runtime python-pyroute2 tries to import json, but the module is not > -available, import simplejson as json solve the issue. > - > -Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br> > ---- > - pyroute2/netlink/rtnl/ifinfmsg.py | 2 +- > - 1 file changed, 1 insertion(+), 1 deletion(-) > - > -diff --git a/pyroute2/netlink/rtnl/ifinfmsg.py b/pyroute2/netlink/rtnl/ > ifinfmsg.py > -index 4f14f25..55643eb 100644 > ---- a/pyroute2/netlink/rtnl/ifinfmsg.py > -+++ b/pyroute2/netlink/rtnl/ifinfmsg.py > -@@ -1,5 +1,5 @@ > - import os > --import json > -+import simplejson as json > - import errno > - import select > - import struct > --- > -2.1.4 > - > diff --git a/meta-python/recipes-devtools/python/python-pyroute2_0.3.22.bb > b/meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb > similarity index 100% > rename from meta-python/recipes-devtools/python/python-pyroute2_0.3.22.bb > rename to meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb > diff --git a/meta-python/recipes-devtools/python/python3- > pyroute2_0.3.22.bb b/meta-python/recipes-devtools/python/python3- > pyroute2_0.4.21.bb > similarity index 100% > rename from meta-python/recipes-devtools/python/python3-pyroute2_0.3.22.bb > rename to meta-python/recipes-devtools/python/python3-pyroute2_0.4.21.bb > -- > 2.7.4 > > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-16 21:58 ` Derek Straka @ 2017-12-18 15:33 ` Mark Asselstine 2017-12-18 15:36 ` Christopher Larson 0 siblings, 1 reply; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 15:33 UTC (permalink / raw) To: Derek Straka; +Cc: openembeded-devel On Sat, Dec 16, 2017 at 4:58 PM, Derek Straka <derek@asterius.io> wrote: > On Mon, Dec 4, 2017 at 2:00 PM, Mark Asselstine < > mark.asselstine@windriver.com> wrote: > >> Drop the json<-->simplejson patch instead opting to depend on >> python-json (part of core python libs). Beyond this the uprev is >> straightforward. >> >> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> >> --- >> .../recipes-devtools/python/python-pyroute2.inc | 23 >> +++++-------------- >> .../import-simplejson-as-json.patch | 26 >> ---------------------- >> ...yroute2_0.3.22.bb => python-pyroute2_0.4.21.bb} | 0 >> ...route2_0.3.22.bb => python3-pyroute2_0.4.21.bb} | 0 >> 4 files changed, 6 insertions(+), 43 deletions(-) >> delete mode 100644 meta-python/recipes-devtools/ >> python/python-pyroute2/import-simplejson-as-json.patch >> rename meta-python/recipes-devtools/python/{python-pyroute2_0.3.22.bb => >> python-pyroute2_0.4.21.bb} (100%) >> rename meta-python/recipes-devtools/python/{python3-pyroute2_0.3.22.bb >> => python3-pyroute2_0.4.21.bb} (100%) >> >> diff --git a/meta-python/recipes-devtools/python/python-pyroute2.inc >> b/meta-python/recipes-devtools/python/python-pyroute2.inc >> index da1d4cd..521162c 100644 >> --- a/meta-python/recipes-devtools/python/python-pyroute2.inc >> +++ b/meta-python/recipes-devtools/python/python-pyroute2.inc >> @@ -1,26 +1,15 @@ >> SUMMARY = "A pure Python netlink and Linux network configuration library" >> LICENSE = "GPLv2 & Apache-2.0" >> LIC_FILES_CHKSUM = "file://LICENSE.GPL.v2;md5= >> b234ee4d69f5fce4486a80fdaf4a4263 \ >> - file://LICENSE.Apache.v2;md5= >> 3b83ef96387f14655fc854ddc3c6bd57" >> + file://LICENSE.Apache.v2;md5= >> 34281e312165f843a2b7d1f114fe65ce" >> >> -SRC_URI[md5sum] = "733adb362b6603c7269c0b3df3045a55" >> -SRC_URI[sha256sum] = "5cdf44656cf623369f0cbf183d9d14 >> a1a50ebdffbd50d4e30ffda62c0a05d7b3" >> - >> -SRC_URI += "file://import-simplejson-as-json.patch" >> +SRC_URI[md5sum] = "9c251543c4282a2f8b1a8d6aa8afc688" >> +SRC_URI[sha256sum] = "7afad28ee0a0f3e7c34adaa9f953d0 >> 0560ed9910203e93f107833b6e8d151171" >> >> > Can we remove the extra path prepend now? > >> FILESEXTRAPATHS_prepend := "${THISDIR}/python-pyroute2:" Sure. I will send a V2 once we get agreement on the RDEPENDS. >> >> inherit pypi >> >> -RDEPENDS_${PN} += "\ >> - ${PYTHON_PN}-distutils \ stdlib >> - ${PYTHON_PN}-simplejson \ per the commit log, use json instead to match upstream expectations. >> - ${PYTHON_PN}-multiprocessing \ stdlib >> - ${PYTHON_PN}-io ${PYTHON_PN}-pprint \ stdlib >> - ${PYTHON_PN}-pickle \ stdlib >> - ${PYTHON_PN}-logging \ stdlib >> - ${PYTHON_PN}-threading \ stdlib >> - ${PYTHON_PN}-textutils \ No reference in this version of pyroute2 >> - ${PYTHON_PN}-subprocess \ stdlib >> - ${PYTHON_PN}-netclient \ No reference in this version of pyroute2 >> -" >> > None of these other dependencies are needed for a minimal python install? Sorry, I should have covered this in my commit log. This was a mistake on my part but was intentional since these are all stdlib modules as I have show above and as is described in the the pyroute2 README: "Pyroute2 is a pure Python **netlink** library. It requires only Python stdlib" All stdlib modules are listed as RDEPENDS in python[3]-modules so we are only making work for ourselves breaking these out here. I will put them back but if we go this route, of listed stdlib RDEPENDS, then there is a lot of work to ensure this is consistent across all our python recipes. Mark > >> +RDEPENDS_${PN} += " \ >> + ${PYTHON_PN}-json \ >> + " >> diff --git a/meta-python/recipes-devtools/python/python- >> pyroute2/import-simplejson-as-json.patch b/meta-python/recipes- >> devtools/python/python-pyroute2/import-simplejson-as-json.patch >> deleted file mode 100644 >> index d73da07..0000000 >> --- a/meta-python/recipes-devtools/python/python- >> pyroute2/import-simplejson-as-json.patch >> +++ /dev/null >> @@ -1,26 +0,0 @@ >> -Upstream-Status: Inappropriate [wrong dependency] >> - >> -Subject: [PATCH] import simplejson as json >> - >> -At runtime python-pyroute2 tries to import json, but the module is not >> -available, import simplejson as json solve the issue. >> - >> -Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br> >> ---- >> - pyroute2/netlink/rtnl/ifinfmsg.py | 2 +- >> - 1 file changed, 1 insertion(+), 1 deletion(-) >> - >> -diff --git a/pyroute2/netlink/rtnl/ifinfmsg.py b/pyroute2/netlink/rtnl/ >> ifinfmsg.py >> -index 4f14f25..55643eb 100644 >> ---- a/pyroute2/netlink/rtnl/ifinfmsg.py >> -+++ b/pyroute2/netlink/rtnl/ifinfmsg.py >> -@@ -1,5 +1,5 @@ >> - import os >> --import json >> -+import simplejson as json >> - import errno >> - import select >> - import struct >> --- >> -2.1.4 >> - >> diff --git a/meta-python/recipes-devtools/python/python-pyroute2_0.3.22.bb >> b/meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb >> similarity index 100% >> rename from meta-python/recipes-devtools/python/python-pyroute2_0.3.22.bb >> rename to meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb >> diff --git a/meta-python/recipes-devtools/python/python3- >> pyroute2_0.3.22.bb b/meta-python/recipes-devtools/python/python3- >> pyroute2_0.4.21.bb >> similarity index 100% >> rename from meta-python/recipes-devtools/python/python3-pyroute2_0.3.22.bb >> rename to meta-python/recipes-devtools/python/python3-pyroute2_0.4.21.bb >> -- >> 2.7.4 >> >> -- >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 15:33 ` Mark Asselstine @ 2017-12-18 15:36 ` Christopher Larson 2017-12-18 16:15 ` Mark Asselstine 0 siblings, 1 reply; 33+ messages in thread From: Christopher Larson @ 2017-12-18 15:36 UTC (permalink / raw) To: Mark Asselstine; +Cc: openembeded-devel All our python recipes should be explicitly listing the python module packages they require. No python module recipes should be depending on python-modules or python3-modules, but explicitly what they require. On Mon, Dec 18, 2017 at 8:33 AM, Mark Asselstine < mark.asselstine@windriver.com> wrote: > On Sat, Dec 16, 2017 at 4:58 PM, Derek Straka <derek@asterius.io> wrote: > > On Mon, Dec 4, 2017 at 2:00 PM, Mark Asselstine < > > mark.asselstine@windriver.com> wrote: > > > >> Drop the json<-->simplejson patch instead opting to depend on > >> python-json (part of core python libs). Beyond this the uprev is > >> straightforward. > >> > >> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> > >> --- > >> .../recipes-devtools/python/python-pyroute2.inc | 23 > >> +++++-------------- > >> .../import-simplejson-as-json.patch | 26 > >> ---------------------- > >> ...yroute2_0.3.22.bb => python-pyroute2_0.4.21.bb} | 0 > >> ...route2_0.3.22.bb => python3-pyroute2_0.4.21.bb} | 0 > >> 4 files changed, 6 insertions(+), 43 deletions(-) > >> delete mode 100644 meta-python/recipes-devtools/ > >> python/python-pyroute2/import-simplejson-as-json.patch > >> rename meta-python/recipes-devtools/python/{python-pyroute2_0.3.22.bb > => > >> python-pyroute2_0.4.21.bb} (100%) > >> rename meta-python/recipes-devtools/python/{python3-pyroute2_0.3.22.bb > >> => python3-pyroute2_0.4.21.bb} (100%) > >> > >> diff --git a/meta-python/recipes-devtools/python/python-pyroute2.inc > >> b/meta-python/recipes-devtools/python/python-pyroute2.inc > >> index da1d4cd..521162c 100644 > >> --- a/meta-python/recipes-devtools/python/python-pyroute2.inc > >> +++ b/meta-python/recipes-devtools/python/python-pyroute2.inc > >> @@ -1,26 +1,15 @@ > >> SUMMARY = "A pure Python netlink and Linux network configuration > library" > >> LICENSE = "GPLv2 & Apache-2.0" > >> LIC_FILES_CHKSUM = "file://LICENSE.GPL.v2;md5= > >> b234ee4d69f5fce4486a80fdaf4a4263 \ > >> - file://LICENSE.Apache.v2;md5= > >> 3b83ef96387f14655fc854ddc3c6bd57" > >> + file://LICENSE.Apache.v2;md5= > >> 34281e312165f843a2b7d1f114fe65ce" > >> > >> -SRC_URI[md5sum] = "733adb362b6603c7269c0b3df3045a55" > >> -SRC_URI[sha256sum] = "5cdf44656cf623369f0cbf183d9d14 > >> a1a50ebdffbd50d4e30ffda62c0a05d7b3" > >> - > >> -SRC_URI += "file://import-simplejson-as-json.patch" > >> +SRC_URI[md5sum] = "9c251543c4282a2f8b1a8d6aa8afc688" > >> +SRC_URI[sha256sum] = "7afad28ee0a0f3e7c34adaa9f953d0 > >> 0560ed9910203e93f107833b6e8d151171" > >> > >> > > Can we remove the extra path prepend now? > > > >> FILESEXTRAPATHS_prepend := "${THISDIR}/python-pyroute2:" > > Sure. I will send a V2 once we get agreement on the RDEPENDS. > > >> > >> inherit pypi > >> > >> -RDEPENDS_${PN} += "\ > >> - ${PYTHON_PN}-distutils \ > > stdlib > > >> - ${PYTHON_PN}-simplejson \ > > per the commit log, use json instead to match upstream expectations. > > >> - ${PYTHON_PN}-multiprocessing \ > > stdlib > > >> - ${PYTHON_PN}-io ${PYTHON_PN}-pprint \ > > stdlib > > >> - ${PYTHON_PN}-pickle \ > > stdlib > > >> - ${PYTHON_PN}-logging \ > > stdlib > > >> - ${PYTHON_PN}-threading \ > > stdlib > > >> - ${PYTHON_PN}-textutils \ > > No reference in this version of pyroute2 > > >> - ${PYTHON_PN}-subprocess \ > > stdlib > > >> - ${PYTHON_PN}-netclient \ > > No reference in this version of pyroute2 > > >> -" > >> > > None of these other dependencies are needed for a minimal python install? > > Sorry, I should have covered this in my commit log. This was a mistake on > my > part but was intentional since these are all stdlib modules as I have show > above and as is described in the the pyroute2 README: > "Pyroute2 is a pure Python **netlink** library. It requires only Python > stdlib" > > All stdlib modules are listed as RDEPENDS in python[3]-modules so we are > only making work for ourselves breaking these out here. I will put them > back > but if we go this route, of listed stdlib RDEPENDS, then there is a lot of > work > to ensure this is consistent across all our python recipes. > > > Mark > > > > > >> +RDEPENDS_${PN} += " \ > >> + ${PYTHON_PN}-json \ > >> + " > >> diff --git a/meta-python/recipes-devtools/python/python- > >> pyroute2/import-simplejson-as-json.patch b/meta-python/recipes- > >> devtools/python/python-pyroute2/import-simplejson-as-json.patch > >> deleted file mode 100644 > >> index d73da07..0000000 > >> --- a/meta-python/recipes-devtools/python/python- > >> pyroute2/import-simplejson-as-json.patch > >> +++ /dev/null > >> @@ -1,26 +0,0 @@ > >> -Upstream-Status: Inappropriate [wrong dependency] > >> - > >> -Subject: [PATCH] import simplejson as json > >> - > >> -At runtime python-pyroute2 tries to import json, but the module is not > >> -available, import simplejson as json solve the issue. > >> - > >> -Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br> > >> ---- > >> - pyroute2/netlink/rtnl/ifinfmsg.py | 2 +- > >> - 1 file changed, 1 insertion(+), 1 deletion(-) > >> - > >> -diff --git a/pyroute2/netlink/rtnl/ifinfmsg.py > b/pyroute2/netlink/rtnl/ > >> ifinfmsg.py > >> -index 4f14f25..55643eb 100644 > >> ---- a/pyroute2/netlink/rtnl/ifinfmsg.py > >> -+++ b/pyroute2/netlink/rtnl/ifinfmsg.py > >> -@@ -1,5 +1,5 @@ > >> - import os > >> --import json > >> -+import simplejson as json > >> - import errno > >> - import select > >> - import struct > >> --- > >> -2.1.4 > >> - > >> diff --git a/meta-python/recipes-devtools/python/python- > pyroute2_0.3.22.bb > >> b/meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb > >> similarity index 100% > >> rename from meta-python/recipes-devtools/python/python-pyroute2_0.3.22. > bb > >> rename to meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb > >> diff --git a/meta-python/recipes-devtools/python/python3- > >> pyroute2_0.3.22.bb b/meta-python/recipes-devtools/python/python3- > >> pyroute2_0.4.21.bb > >> similarity index 100% > >> rename from meta-python/recipes-devtools/python/python3-pyroute2_0.3. > 22.bb > >> rename to meta-python/recipes-devtools/python/python3-pyroute2_0.4. > 21.bb > >> -- > >> 2.7.4 > >> > >> -- > >> _______________________________________________ > >> Openembedded-devel mailing list > >> Openembedded-devel@lists.openembedded.org > >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> > > -- > > _______________________________________________ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 15:36 ` Christopher Larson @ 2017-12-18 16:15 ` Mark Asselstine 2017-12-18 16:37 ` Alexander Kanavin 0 siblings, 1 reply; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 16:15 UTC (permalink / raw) To: Christopher Larson; +Cc: openembeded-devel On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com> wrote: > All our python recipes should be explicitly listing the python module > packages they require. No python module recipes should be depending on > python-modules or python3-modules, but explicitly what they require. This is a giant PITA for little gain in my opinion. The typical python 'vehicles' to define dependencies, things like setup.py, requires.txt, requirements.txt..., never bother to list stdlibs. These are standard libs that are just expected to be there. If a system is being installed with only select python modules it will behave differently than python found on any other system violating the rule of least surprise. On top of this most of these modules are ~40K in size and there are roughly 60 in the stdlib so the size gain in installing a few vs. all of them is extremely negligible. All of this seems to add way more work and churn that outweighs any real benefit. Mark > > On Mon, Dec 18, 2017 at 8:33 AM, Mark Asselstine < > mark.asselstine@windriver.com> wrote: > >> On Sat, Dec 16, 2017 at 4:58 PM, Derek Straka <derek@asterius.io> wrote: >> > On Mon, Dec 4, 2017 at 2:00 PM, Mark Asselstine < >> > mark.asselstine@windriver.com> wrote: >> > >> >> Drop the json<-->simplejson patch instead opting to depend on >> >> python-json (part of core python libs). Beyond this the uprev is >> >> straightforward. >> >> >> >> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> >> >> --- >> >> .../recipes-devtools/python/python-pyroute2.inc | 23 >> >> +++++-------------- >> >> .../import-simplejson-as-json.patch | 26 >> >> ---------------------- >> >> ...yroute2_0.3.22.bb => python-pyroute2_0.4.21.bb} | 0 >> >> ...route2_0.3.22.bb => python3-pyroute2_0.4.21.bb} | 0 >> >> 4 files changed, 6 insertions(+), 43 deletions(-) >> >> delete mode 100644 meta-python/recipes-devtools/ >> >> python/python-pyroute2/import-simplejson-as-json.patch >> >> rename meta-python/recipes-devtools/python/{python-pyroute2_0.3.22.bb >> => >> >> python-pyroute2_0.4.21.bb} (100%) >> >> rename meta-python/recipes-devtools/python/{python3-pyroute2_0.3.22.bb >> >> => python3-pyroute2_0.4.21.bb} (100%) >> >> >> >> diff --git a/meta-python/recipes-devtools/python/python-pyroute2.inc >> >> b/meta-python/recipes-devtools/python/python-pyroute2.inc >> >> index da1d4cd..521162c 100644 >> >> --- a/meta-python/recipes-devtools/python/python-pyroute2.inc >> >> +++ b/meta-python/recipes-devtools/python/python-pyroute2.inc >> >> @@ -1,26 +1,15 @@ >> >> SUMMARY = "A pure Python netlink and Linux network configuration >> library" >> >> LICENSE = "GPLv2 & Apache-2.0" >> >> LIC_FILES_CHKSUM = "file://LICENSE.GPL.v2;md5= >> >> b234ee4d69f5fce4486a80fdaf4a4263 \ >> >> - file://LICENSE.Apache.v2;md5= >> >> 3b83ef96387f14655fc854ddc3c6bd57" >> >> + file://LICENSE.Apache.v2;md5= >> >> 34281e312165f843a2b7d1f114fe65ce" >> >> >> >> -SRC_URI[md5sum] = "733adb362b6603c7269c0b3df3045a55" >> >> -SRC_URI[sha256sum] = "5cdf44656cf623369f0cbf183d9d14 >> >> a1a50ebdffbd50d4e30ffda62c0a05d7b3" >> >> - >> >> -SRC_URI += "file://import-simplejson-as-json.patch" >> >> +SRC_URI[md5sum] = "9c251543c4282a2f8b1a8d6aa8afc688" >> >> +SRC_URI[sha256sum] = "7afad28ee0a0f3e7c34adaa9f953d0 >> >> 0560ed9910203e93f107833b6e8d151171" >> >> >> >> >> > Can we remove the extra path prepend now? >> > >> >> FILESEXTRAPATHS_prepend := "${THISDIR}/python-pyroute2:" >> >> Sure. I will send a V2 once we get agreement on the RDEPENDS. >> >> >> >> >> inherit pypi >> >> >> >> -RDEPENDS_${PN} += "\ >> >> - ${PYTHON_PN}-distutils \ >> >> stdlib >> >> >> - ${PYTHON_PN}-simplejson \ >> >> per the commit log, use json instead to match upstream expectations. >> >> >> - ${PYTHON_PN}-multiprocessing \ >> >> stdlib >> >> >> - ${PYTHON_PN}-io ${PYTHON_PN}-pprint \ >> >> stdlib >> >> >> - ${PYTHON_PN}-pickle \ >> >> stdlib >> >> >> - ${PYTHON_PN}-logging \ >> >> stdlib >> >> >> - ${PYTHON_PN}-threading \ >> >> stdlib >> >> >> - ${PYTHON_PN}-textutils \ >> >> No reference in this version of pyroute2 >> >> >> - ${PYTHON_PN}-subprocess \ >> >> stdlib >> >> >> - ${PYTHON_PN}-netclient \ >> >> No reference in this version of pyroute2 >> >> >> -" >> >> >> > None of these other dependencies are needed for a minimal python install? >> >> Sorry, I should have covered this in my commit log. This was a mistake on >> my >> part but was intentional since these are all stdlib modules as I have show >> above and as is described in the the pyroute2 README: >> "Pyroute2 is a pure Python **netlink** library. It requires only Python >> stdlib" >> >> All stdlib modules are listed as RDEPENDS in python[3]-modules so we are >> only making work for ourselves breaking these out here. I will put them >> back >> but if we go this route, of listed stdlib RDEPENDS, then there is a lot of >> work >> to ensure this is consistent across all our python recipes. >> >> >> Mark >> >> >> > >> >> +RDEPENDS_${PN} += " \ >> >> + ${PYTHON_PN}-json \ >> >> + " >> >> diff --git a/meta-python/recipes-devtools/python/python- >> >> pyroute2/import-simplejson-as-json.patch b/meta-python/recipes- >> >> devtools/python/python-pyroute2/import-simplejson-as-json.patch >> >> deleted file mode 100644 >> >> index d73da07..0000000 >> >> --- a/meta-python/recipes-devtools/python/python- >> >> pyroute2/import-simplejson-as-json.patch >> >> +++ /dev/null >> >> @@ -1,26 +0,0 @@ >> >> -Upstream-Status: Inappropriate [wrong dependency] >> >> - >> >> -Subject: [PATCH] import simplejson as json >> >> - >> >> -At runtime python-pyroute2 tries to import json, but the module is not >> >> -available, import simplejson as json solve the issue. >> >> - >> >> -Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br> >> >> ---- >> >> - pyroute2/netlink/rtnl/ifinfmsg.py | 2 +- >> >> - 1 file changed, 1 insertion(+), 1 deletion(-) >> >> - >> >> -diff --git a/pyroute2/netlink/rtnl/ifinfmsg.py >> b/pyroute2/netlink/rtnl/ >> >> ifinfmsg.py >> >> -index 4f14f25..55643eb 100644 >> >> ---- a/pyroute2/netlink/rtnl/ifinfmsg.py >> >> -+++ b/pyroute2/netlink/rtnl/ifinfmsg.py >> >> -@@ -1,5 +1,5 @@ >> >> - import os >> >> --import json >> >> -+import simplejson as json >> >> - import errno >> >> - import select >> >> - import struct >> >> --- >> >> -2.1.4 >> >> - >> >> diff --git a/meta-python/recipes-devtools/python/python- >> pyroute2_0.3.22.bb >> >> b/meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb >> >> similarity index 100% >> >> rename from meta-python/recipes-devtools/python/python-pyroute2_0.3.22. >> bb >> >> rename to meta-python/recipes-devtools/python/python-pyroute2_0.4.21.bb >> >> diff --git a/meta-python/recipes-devtools/python/python3- >> >> pyroute2_0.3.22.bb b/meta-python/recipes-devtools/python/python3- >> >> pyroute2_0.4.21.bb >> >> similarity index 100% >> >> rename from meta-python/recipes-devtools/python/python3-pyroute2_0.3. >> 22.bb >> >> rename to meta-python/recipes-devtools/python/python3-pyroute2_0.4. >> 21.bb >> >> -- >> >> 2.7.4 >> >> >> >> -- >> >> _______________________________________________ >> >> Openembedded-devel mailing list >> >> Openembedded-devel@lists.openembedded.org >> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> >> >> > -- >> > _______________________________________________ >> > Openembedded-devel mailing list >> > Openembedded-devel@lists.openembedded.org >> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> -- >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> > > > > -- > Christopher Larson > kergoth at gmail dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Senior Software Engineer, Mentor Graphics > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 16:15 ` Mark Asselstine @ 2017-12-18 16:37 ` Alexander Kanavin 0 siblings, 0 replies; 33+ messages in thread From: Alexander Kanavin @ 2017-12-18 16:37 UTC (permalink / raw) To: mark.asselstine, Christopher Larson Cc: openembeded-devel, Patches and discussions about the oe-core layer On 12/18/2017 06:15 PM, Mark Asselstine wrote: > On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com> wrote: >> All our python recipes should be explicitly listing the python module >> packages they require. No python module recipes should be depending on >> python-modules or python3-modules, but explicitly what they require. > > This is a giant PITA for little gain in my opinion. The typical python > 'vehicles' to define dependencies, things like setup.py, requires.txt, > requirements.txt..., never bother to list stdlibs. These are standard > libs that are just expected to be there. If a system is being > installed with only select python modules it will behave differently > than python found on any other system violating the rule of least > surprise. On top of this most of these modules are ~40K in size and > there are roughly 60 in the stdlib so the size gain in installing a > few vs. all of them is extremely negligible. All of this seems to add > way more work and churn that outweighs any real benefit. I tend to agree with this. Add also the situation that the yocto project needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 soon after, no one has enough time to do this rather non-trivial job, and I'm beginning to wonder if the best way out is to remove the module splitting altogether, and write a clean, simple and maintainable python3 recipe from scratch with minimal amount of custom patching and hopefully no write-only hacks. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-18 16:37 ` Alexander Kanavin 0 siblings, 0 replies; 33+ messages in thread From: Alexander Kanavin @ 2017-12-18 16:37 UTC (permalink / raw) To: mark.asselstine, Christopher Larson Cc: openembeded-devel, Patches and discussions about the oe-core layer On 12/18/2017 06:15 PM, Mark Asselstine wrote: > On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com> wrote: >> All our python recipes should be explicitly listing the python module >> packages they require. No python module recipes should be depending on >> python-modules or python3-modules, but explicitly what they require. > > This is a giant PITA for little gain in my opinion. The typical python > 'vehicles' to define dependencies, things like setup.py, requires.txt, > requirements.txt..., never bother to list stdlibs. These are standard > libs that are just expected to be there. If a system is being > installed with only select python modules it will behave differently > than python found on any other system violating the rule of least > surprise. On top of this most of these modules are ~40K in size and > there are roughly 60 in the stdlib so the size gain in installing a > few vs. all of them is extremely negligible. All of this seems to add > way more work and churn that outweighs any real benefit. I tend to agree with this. Add also the situation that the yocto project needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 soon after, no one has enough time to do this rather non-trivial job, and I'm beginning to wonder if the best way out is to remove the module splitting altogether, and write a clean, simple and maintainable python3 recipe from scratch with minimal amount of custom patching and hopefully no write-only hacks. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 16:37 ` Alexander Kanavin @ 2017-12-18 16:56 ` Mark Asselstine -1 siblings, 0 replies; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 16:56 UTC (permalink / raw) To: Alexander Kanavin Cc: openembeded-devel, Patches and discussions about the oe-core layer On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote: > On 12/18/2017 06:15 PM, Mark Asselstine wrote: >> >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com> >> wrote: >>> >>> All our python recipes should be explicitly listing the python module >>> packages they require. No python module recipes should be depending on >>> python-modules or python3-modules, but explicitly what they require. >> >> >> This is a giant PITA for little gain in my opinion. The typical python >> 'vehicles' to define dependencies, things like setup.py, requires.txt, >> requirements.txt..., never bother to list stdlibs. These are standard >> libs that are just expected to be there. If a system is being >> installed with only select python modules it will behave differently >> than python found on any other system violating the rule of least >> surprise. On top of this most of these modules are ~40K in size and >> there are roughly 60 in the stdlib so the size gain in installing a >> few vs. all of them is extremely negligible. All of this seems to add >> way more work and churn that outweighs any real benefit. > > > I tend to agree with this. Add also the situation that the yocto project > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 soon > after, no one has enough time to do this rather non-trivial job, and I'm > beginning to wonder if the best way out is to remove the module splitting > altogether, and write a clean, simple and maintainable python3 recipe from > scratch with minimal amount of custom patching and hopefully no write-only > hacks. > > Alex Thanks Alex for the support. To get a better idea as to what the size delta is I took the installed sizes from a rootfs logfile and the total size for all modules (python2.7) is 6.5M python-misc is almost 2M of this and python-codecs contributing over 0.5M. The savings will never be the full 6.5M as there will always be python-lang and some other modules needed. There was a time where 32M restrictions existed are some systems but are we really seeing devices with these restrictions any more? what about exploring not shipping the pyc files? I would much rather see this than imposing so much work and churn for very little gain. Anyways, maybe this isn't the best forum for this and it should be brought up to the architecture group. Mark > > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-18 16:56 ` Mark Asselstine 0 siblings, 0 replies; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 16:56 UTC (permalink / raw) To: Alexander Kanavin Cc: openembeded-devel, Patches and discussions about the oe-core layer On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote: > On 12/18/2017 06:15 PM, Mark Asselstine wrote: >> >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com> >> wrote: >>> >>> All our python recipes should be explicitly listing the python module >>> packages they require. No python module recipes should be depending on >>> python-modules or python3-modules, but explicitly what they require. >> >> >> This is a giant PITA for little gain in my opinion. The typical python >> 'vehicles' to define dependencies, things like setup.py, requires.txt, >> requirements.txt..., never bother to list stdlibs. These are standard >> libs that are just expected to be there. If a system is being >> installed with only select python modules it will behave differently >> than python found on any other system violating the rule of least >> surprise. On top of this most of these modules are ~40K in size and >> there are roughly 60 in the stdlib so the size gain in installing a >> few vs. all of them is extremely negligible. All of this seems to add >> way more work and churn that outweighs any real benefit. > > > I tend to agree with this. Add also the situation that the yocto project > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 soon > after, no one has enough time to do this rather non-trivial job, and I'm > beginning to wonder if the best way out is to remove the module splitting > altogether, and write a clean, simple and maintainable python3 recipe from > scratch with minimal amount of custom patching and hopefully no write-only > hacks. > > Alex Thanks Alex for the support. To get a better idea as to what the size delta is I took the installed sizes from a rootfs logfile and the total size for all modules (python2.7) is 6.5M python-misc is almost 2M of this and python-codecs contributing over 0.5M. The savings will never be the full 6.5M as there will always be python-lang and some other modules needed. There was a time where 32M restrictions existed are some systems but are we really seeing devices with these restrictions any more? what about exploring not shipping the pyc files? I would much rather see this than imposing so much work and churn for very little gain. Anyways, maybe this isn't the best forum for this and it should be brought up to the architecture group. Mark > > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 16:56 ` Mark Asselstine @ 2017-12-18 20:17 ` Derek Straka -1 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-18 20:17 UTC (permalink / raw) To: Mark Asselstine Cc: openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3857 bytes --] I have several customers who have optimized for space and would like to see the capability maintained unless core removes the ability to split python packages out. They also remove the *.py files in favor of *.pyo files (via a custom packaging mechanism). I have automated tests that go through the module importing on each of the meta-python packages to ensure it works on minimal python installations. When other contributors don't do provide that functionality, I either catch it when I do package update or when it breaks for one of my customers. I'm fine if you don't want to perform the checks yourself and it breaks my use case with missing dependencies, but I would prefer that you don't remove the dependencies that are currently in place. Thanks. -Derek On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine < mark.asselstine@windriver.com> wrote: > On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin > <alexander.kanavin@linux.intel.com> wrote: > > On 12/18/2017 06:15 PM, Mark Asselstine wrote: > >> > >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com > > > >> wrote: > >>> > >>> All our python recipes should be explicitly listing the python module > >>> packages they require. No python module recipes should be depending on > >>> python-modules or python3-modules, but explicitly what they require. > >> > >> > >> This is a giant PITA for little gain in my opinion. The typical python > >> 'vehicles' to define dependencies, things like setup.py, requires.txt, > >> requirements.txt..., never bother to list stdlibs. These are standard > >> libs that are just expected to be there. If a system is being > >> installed with only select python modules it will behave differently > >> than python found on any other system violating the rule of least > >> surprise. On top of this most of these modules are ~40K in size and > >> there are roughly 60 in the stdlib so the size gain in installing a > >> few vs. all of them is extremely negligible. All of this seems to add > >> way more work and churn that outweighs any real benefit. > > > > > > I tend to agree with this. Add also the situation that the yocto project > > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 > soon > > after, no one has enough time to do this rather non-trivial job, and I'm > > beginning to wonder if the best way out is to remove the module splitting > > altogether, and write a clean, simple and maintainable python3 recipe > from > > scratch with minimal amount of custom patching and hopefully no > write-only > > hacks. > > > > Alex > > Thanks Alex for the support. To get a better idea as to what the size > delta is I took the installed sizes from a rootfs logfile and the > total size for all modules (python2.7) is 6.5M python-misc is almost > 2M of this and python-codecs contributing over 0.5M. The savings will > never be the full 6.5M as there will always be python-lang and some > other modules needed. There was a time where 32M restrictions existed > are some systems but are we really seeing devices with these > restrictions any more? what about exploring not shipping the pyc > files? I would much rather see this than imposing so much work and > churn for very little gain. Anyways, maybe this isn't the best forum > for this and it should be brought up to the architecture group. > > Mark > > > > > -- > > _______________________________________________ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > [-- Attachment #2: Type: text/html, Size: 5145 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-18 20:17 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-18 20:17 UTC (permalink / raw) To: Mark Asselstine Cc: openembeded-devel, Patches and discussions about the oe-core layer I have several customers who have optimized for space and would like to see the capability maintained unless core removes the ability to split python packages out. They also remove the *.py files in favor of *.pyo files (via a custom packaging mechanism). I have automated tests that go through the module importing on each of the meta-python packages to ensure it works on minimal python installations. When other contributors don't do provide that functionality, I either catch it when I do package update or when it breaks for one of my customers. I'm fine if you don't want to perform the checks yourself and it breaks my use case with missing dependencies, but I would prefer that you don't remove the dependencies that are currently in place. Thanks. -Derek On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine < mark.asselstine@windriver.com> wrote: > On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin > <alexander.kanavin@linux.intel.com> wrote: > > On 12/18/2017 06:15 PM, Mark Asselstine wrote: > >> > >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com > > > >> wrote: > >>> > >>> All our python recipes should be explicitly listing the python module > >>> packages they require. No python module recipes should be depending on > >>> python-modules or python3-modules, but explicitly what they require. > >> > >> > >> This is a giant PITA for little gain in my opinion. The typical python > >> 'vehicles' to define dependencies, things like setup.py, requires.txt, > >> requirements.txt..., never bother to list stdlibs. These are standard > >> libs that are just expected to be there. If a system is being > >> installed with only select python modules it will behave differently > >> than python found on any other system violating the rule of least > >> surprise. On top of this most of these modules are ~40K in size and > >> there are roughly 60 in the stdlib so the size gain in installing a > >> few vs. all of them is extremely negligible. All of this seems to add > >> way more work and churn that outweighs any real benefit. > > > > > > I tend to agree with this. Add also the situation that the yocto project > > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 > soon > > after, no one has enough time to do this rather non-trivial job, and I'm > > beginning to wonder if the best way out is to remove the module splitting > > altogether, and write a clean, simple and maintainable python3 recipe > from > > scratch with minimal amount of custom patching and hopefully no > write-only > > hacks. > > > > Alex > > Thanks Alex for the support. To get a better idea as to what the size > delta is I took the installed sizes from a rootfs logfile and the > total size for all modules (python2.7) is 6.5M python-misc is almost > 2M of this and python-codecs contributing over 0.5M. The savings will > never be the full 6.5M as there will always be python-lang and some > other modules needed. There was a time where 32M restrictions existed > are some systems but are we really seeing devices with these > restrictions any more? what about exploring not shipping the pyc > files? I would much rather see this than imposing so much work and > churn for very little gain. Anyways, maybe this isn't the best forum > for this and it should be brought up to the architecture group. > > Mark > > > > > -- > > _______________________________________________ > > Openembedded-devel mailing list > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 20:17 ` Derek Straka @ 2017-12-18 20:53 ` Mark Asselstine -1 siblings, 0 replies; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 20:53 UTC (permalink / raw) To: Derek Straka Cc: openembeded-devel, Patches and discussions about the oe-core layer On Mon, Dec 18, 2017 at 3:17 PM, Derek Straka <derek@asterius.io> wrote: > I have several customers who have optimized for space and would like to see > the capability maintained unless core removes the ability to split python > packages out. They also remove the *.py files in favor of *.pyo files (via > a custom packaging mechanism). I have automated tests that go through the > module importing on each of the meta-python packages to ensure it works on > minimal python installations. When other contributors don't do provide > that functionality, I either catch it when I do package update or when it > breaks for one of my customers. I'm fine if you don't want to perform the > checks yourself and it breaks my use case with missing dependencies, but I > would prefer that you don't remove the dependencies that are currently in > place. Thanks. I can respect this approach. I will put the RDEPENDS back and send out a V2. As for the overall approach being applied to all python recipes, my opinion still stands that this is such a small subset that we are devoting time better spent elsewhere to service the few. Mark > > -Derek > > On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine < > mark.asselstine@windriver.com> wrote: > >> On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin >> <alexander.kanavin@linux.intel.com> wrote: >> > On 12/18/2017 06:15 PM, Mark Asselstine wrote: >> >> >> >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com >> > >> >> wrote: >> >>> >> >>> All our python recipes should be explicitly listing the python module >> >>> packages they require. No python module recipes should be depending on >> >>> python-modules or python3-modules, but explicitly what they require. >> >> >> >> >> >> This is a giant PITA for little gain in my opinion. The typical python >> >> 'vehicles' to define dependencies, things like setup.py, requires.txt, >> >> requirements.txt..., never bother to list stdlibs. These are standard >> >> libs that are just expected to be there. If a system is being >> >> installed with only select python modules it will behave differently >> >> than python found on any other system violating the rule of least >> >> surprise. On top of this most of these modules are ~40K in size and >> >> there are roughly 60 in the stdlib so the size gain in installing a >> >> few vs. all of them is extremely negligible. All of this seems to add >> >> way more work and churn that outweighs any real benefit. >> > >> > >> > I tend to agree with this. Add also the situation that the yocto project >> > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 >> soon >> > after, no one has enough time to do this rather non-trivial job, and I'm >> > beginning to wonder if the best way out is to remove the module splitting >> > altogether, and write a clean, simple and maintainable python3 recipe >> from >> > scratch with minimal amount of custom patching and hopefully no >> write-only >> > hacks. >> > >> > Alex >> >> Thanks Alex for the support. To get a better idea as to what the size >> delta is I took the installed sizes from a rootfs logfile and the >> total size for all modules (python2.7) is 6.5M python-misc is almost >> 2M of this and python-codecs contributing over 0.5M. The savings will >> never be the full 6.5M as there will always be python-lang and some >> other modules needed. There was a time where 32M restrictions existed >> are some systems but are we really seeing devices with these >> restrictions any more? what about exploring not shipping the pyc >> files? I would much rather see this than imposing so much work and >> churn for very little gain. Anyways, maybe this isn't the best forum >> for this and it should be brought up to the architecture group. >> >> Mark >> >> > >> > -- >> > _______________________________________________ >> > Openembedded-devel mailing list >> > Openembedded-devel@lists.openembedded.org >> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> -- >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-18 20:53 ` Mark Asselstine 0 siblings, 0 replies; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 20:53 UTC (permalink / raw) To: Derek Straka Cc: openembeded-devel, Patches and discussions about the oe-core layer On Mon, Dec 18, 2017 at 3:17 PM, Derek Straka <derek@asterius.io> wrote: > I have several customers who have optimized for space and would like to see > the capability maintained unless core removes the ability to split python > packages out. They also remove the *.py files in favor of *.pyo files (via > a custom packaging mechanism). I have automated tests that go through the > module importing on each of the meta-python packages to ensure it works on > minimal python installations. When other contributors don't do provide > that functionality, I either catch it when I do package update or when it > breaks for one of my customers. I'm fine if you don't want to perform the > checks yourself and it breaks my use case with missing dependencies, but I > would prefer that you don't remove the dependencies that are currently in > place. Thanks. I can respect this approach. I will put the RDEPENDS back and send out a V2. As for the overall approach being applied to all python recipes, my opinion still stands that this is such a small subset that we are devoting time better spent elsewhere to service the few. Mark > > -Derek > > On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine < > mark.asselstine@windriver.com> wrote: > >> On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin >> <alexander.kanavin@linux.intel.com> wrote: >> > On 12/18/2017 06:15 PM, Mark Asselstine wrote: >> >> >> >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@gmail.com >> > >> >> wrote: >> >>> >> >>> All our python recipes should be explicitly listing the python module >> >>> packages they require. No python module recipes should be depending on >> >>> python-modules or python3-modules, but explicitly what they require. >> >> >> >> >> >> This is a giant PITA for little gain in my opinion. The typical python >> >> 'vehicles' to define dependencies, things like setup.py, requires.txt, >> >> requirements.txt..., never bother to list stdlibs. These are standard >> >> libs that are just expected to be there. If a system is being >> >> installed with only select python modules it will behave differently >> >> than python found on any other system violating the rule of least >> >> surprise. On top of this most of these modules are ~40K in size and >> >> there are roughly 60 in the stdlib so the size gain in installing a >> >> few vs. all of them is extremely negligible. All of this seems to add >> >> way more work and churn that outweighs any real benefit. >> > >> > >> > I tend to agree with this. Add also the situation that the yocto project >> > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 >> soon >> > after, no one has enough time to do this rather non-trivial job, and I'm >> > beginning to wonder if the best way out is to remove the module splitting >> > altogether, and write a clean, simple and maintainable python3 recipe >> from >> > scratch with minimal amount of custom patching and hopefully no >> write-only >> > hacks. >> > >> > Alex >> >> Thanks Alex for the support. To get a better idea as to what the size >> delta is I took the installed sizes from a rootfs logfile and the >> total size for all modules (python2.7) is 6.5M python-misc is almost >> 2M of this and python-codecs contributing over 0.5M. The savings will >> never be the full 6.5M as there will always be python-lang and some >> other modules needed. There was a time where 32M restrictions existed >> are some systems but are we really seeing devices with these >> restrictions any more? what about exploring not shipping the pyc >> files? I would much rather see this than imposing so much work and >> churn for very little gain. Anyways, maybe this isn't the best forum >> for this and it should be brought up to the architecture group. >> >> Mark >> >> > >> > -- >> > _______________________________________________ >> > Openembedded-devel mailing list >> > Openembedded-devel@lists.openembedded.org >> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> -- >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 20:17 ` Derek Straka (?) (?) @ 2017-12-18 21:02 ` S. Lockwood-Childs 2017-12-18 21:07 ` Derek Straka 2017-12-19 7:56 ` splitting python's standard library Alexander Kanavin -1 siblings, 2 replies; 33+ messages in thread From: S. Lockwood-Childs @ 2017-12-18 21:02 UTC (permalink / raw) To: Derek Straka Cc: Mark Asselstine, openembeded-devel, Patches and discussions about the oe-core layer On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > I have several customers who have optimized for space and would like to see > the capability maintained unless core removes the ability to split python > packages out. They also remove the *.py files in favor of *.pyo files (via > a custom packaging mechanism). I have automated tests that go through the > module importing on each of the meta-python packages to ensure it works on > minimal python installations. When other contributors don't do provide > that functionality, I either catch it when I do package update or when it > breaks for one of my customers. I'm fine if you don't want to perform the > checks yourself and it breaks my use case with missing dependencies, but I > would prefer that you don't remove the dependencies that are currently in > place. Thanks. Me too -- some of my projects still use NAND for rootfs, where space is tight and ability to split out python modules is very useful. Thus it is not an unused feature, though many projects have SD/eMMC for rootfs and those ones generally will not care about it. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 21:02 ` S. Lockwood-Childs @ 2017-12-18 21:07 ` Derek Straka 2017-12-19 7:56 ` splitting python's standard library Alexander Kanavin 1 sibling, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-18 21:07 UTC (permalink / raw) To: S. Lockwood-Childs, Derek Straka, Mark Asselstine, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1415 bytes --] I also need to look at the UPSTREAM_CHECK_URI for this recipe since it isn't finding the latest version and telling me to update the package. On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> wrote: > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > > I have several customers who have optimized for space and would like to > see > > the capability maintained unless core removes the ability to split python > > packages out. They also remove the *.py files in favor of *.pyo files > (via > > a custom packaging mechanism). I have automated tests that go through > the > > module importing on each of the meta-python packages to ensure it works > on > > minimal python installations. When other contributors don't do provide > > that functionality, I either catch it when I do package update or when it > > breaks for one of my customers. I'm fine if you don't want to perform > the > > checks yourself and it breaks my use case with missing dependencies, but > I > > would prefer that you don't remove the dependencies that are currently in > > place. Thanks. > > Me too -- some of my projects still use NAND for rootfs, where space is > tight and > ability to split out python modules is very useful. Thus it is not an > unused > feature, though many projects have SD/eMMC for rootfs and those ones > generally > will not care about it. > [-- Attachment #2: Type: text/html, Size: 1824 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-18 21:07 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-18 21:07 UTC (permalink / raw) To: S. Lockwood-Childs, Derek Straka, Mark Asselstine, openembeded-devel, Patches and discussions about the oe-core layer I also need to look at the UPSTREAM_CHECK_URI for this recipe since it isn't finding the latest version and telling me to update the package. On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> wrote: > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > > I have several customers who have optimized for space and would like to > see > > the capability maintained unless core removes the ability to split python > > packages out. They also remove the *.py files in favor of *.pyo files > (via > > a custom packaging mechanism). I have automated tests that go through > the > > module importing on each of the meta-python packages to ensure it works > on > > minimal python installations. When other contributors don't do provide > > that functionality, I either catch it when I do package update or when it > > breaks for one of my customers. I'm fine if you don't want to perform > the > > checks yourself and it breaks my use case with missing dependencies, but > I > > would prefer that you don't remove the dependencies that are currently in > > place. Thanks. > > Me too -- some of my projects still use NAND for rootfs, where space is > tight and > ability to split out python modules is very useful. Thus it is not an > unused > feature, though many projects have SD/eMMC for rootfs and those ones > generally > will not care about it. > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 21:07 ` Derek Straka @ 2017-12-18 21:26 ` Mark Asselstine -1 siblings, 0 replies; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 21:26 UTC (permalink / raw) To: Derek Straka Cc: S. Lockwood-Childs, openembeded-devel, Patches and discussions about the oe-core layer On Monday, December 18, 2017 4:07:44 PM EST Derek Straka wrote: > I also need to look at the UPSTREAM_CHECK_URI for this recipe since it > isn't finding the latest version and telling me to update the package. Odd. Let me know how it goes. If it is easier for you to make the changes locally and complete the merge go for it. Mark > > On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> wrote: > > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > > > I have several customers who have optimized for space and would like to > > > > see > > > > > the capability maintained unless core removes the ability to split > > > python > > > packages out. They also remove the *.py files in favor of *.pyo files > > > > (via > > > > > a custom packaging mechanism). I have automated tests that go through > > > > the > > > > > module importing on each of the meta-python packages to ensure it works > > > > on > > > > > minimal python installations. When other contributors don't do provide > > > that functionality, I either catch it when I do package update or when > > > it > > > breaks for one of my customers. I'm fine if you don't want to perform > > > > the > > > > > checks yourself and it breaks my use case with missing dependencies, but > > > > I > > > > > would prefer that you don't remove the dependencies that are currently > > > in > > > place. Thanks. > > > > Me too -- some of my projects still use NAND for rootfs, where space is > > tight and > > ability to split out python modules is very useful. Thus it is not an > > unused > > feature, though many projects have SD/eMMC for rootfs and those ones > > generally > > will not care about it. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-18 21:26 ` Mark Asselstine 0 siblings, 0 replies; 33+ messages in thread From: Mark Asselstine @ 2017-12-18 21:26 UTC (permalink / raw) To: Derek Straka Cc: openembeded-devel, Patches and discussions about the oe-core layer On Monday, December 18, 2017 4:07:44 PM EST Derek Straka wrote: > I also need to look at the UPSTREAM_CHECK_URI for this recipe since it > isn't finding the latest version and telling me to update the package. Odd. Let me know how it goes. If it is easier for you to make the changes locally and complete the merge go for it. Mark > > On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> wrote: > > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > > > I have several customers who have optimized for space and would like to > > > > see > > > > > the capability maintained unless core removes the ability to split > > > python > > > packages out. They also remove the *.py files in favor of *.pyo files > > > > (via > > > > > a custom packaging mechanism). I have automated tests that go through > > > > the > > > > > module importing on each of the meta-python packages to ensure it works > > > > on > > > > > minimal python installations. When other contributors don't do provide > > > that functionality, I either catch it when I do package update or when > > > it > > > breaks for one of my customers. I'm fine if you don't want to perform > > > > the > > > > > checks yourself and it breaks my use case with missing dependencies, but > > > > I > > > > > would prefer that you don't remove the dependencies that are currently > > > in > > > place. Thanks. > > > > Me too -- some of my projects still use NAND for rootfs, where space is > > tight and > > ability to split out python modules is very useful. Thus it is not an > > unused > > feature, though many projects have SD/eMMC for rootfs and those ones > > generally > > will not care about it. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) 2017-12-18 21:26 ` Mark Asselstine @ 2017-12-18 21:27 ` Derek Straka -1 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-18 21:27 UTC (permalink / raw) To: Mark Asselstine Cc: S. Lockwood-Childs, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 2034 bytes --] Go ahead and do a v2, it was more of a reminder for me. On Mon, Dec 18, 2017 at 4:26 PM, Mark Asselstine < mark.asselstine@windriver.com> wrote: > On Monday, December 18, 2017 4:07:44 PM EST Derek Straka wrote: > > I also need to look at the UPSTREAM_CHECK_URI for this recipe since it > > isn't finding the latest version and telling me to update the package. > > Odd. Let me know how it goes. If it is easier for you to make the changes > locally and complete the merge go for it. > > Mark > > > > > On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> > wrote: > > > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > > > > I have several customers who have optimized for space and would like > to > > > > > > see > > > > > > > the capability maintained unless core removes the ability to split > > > > python > > > > packages out. They also remove the *.py files in favor of *.pyo > files > > > > > > (via > > > > > > > a custom packaging mechanism). I have automated tests that go > through > > > > > > the > > > > > > > module importing on each of the meta-python packages to ensure it > works > > > > > > on > > > > > > > minimal python installations. When other contributors don't do > provide > > > > that functionality, I either catch it when I do package update or > when > > > > it > > > > breaks for one of my customers. I'm fine if you don't want to > perform > > > > > > the > > > > > > > checks yourself and it breaks my use case with missing dependencies, > but > > > > > > I > > > > > > > would prefer that you don't remove the dependencies that are > currently > > > > in > > > > place. Thanks. > > > > > > Me too -- some of my projects still use NAND for rootfs, where space is > > > tight and > > > ability to split out python modules is very useful. Thus it is not an > > > unused > > > feature, though many projects have SD/eMMC for rootfs and those ones > > > generally > > > will not care about it. > > [-- Attachment #2: Type: text/html, Size: 2904 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) @ 2017-12-18 21:27 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-18 21:27 UTC (permalink / raw) To: Mark Asselstine Cc: openembeded-devel, Patches and discussions about the oe-core layer Go ahead and do a v2, it was more of a reminder for me. On Mon, Dec 18, 2017 at 4:26 PM, Mark Asselstine < mark.asselstine@windriver.com> wrote: > On Monday, December 18, 2017 4:07:44 PM EST Derek Straka wrote: > > I also need to look at the UPSTREAM_CHECK_URI for this recipe since it > > isn't finding the latest version and telling me to update the package. > > Odd. Let me know how it goes. If it is easier for you to make the changes > locally and complete the merge go for it. > > Mark > > > > > On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> > wrote: > > > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > > > > I have several customers who have optimized for space and would like > to > > > > > > see > > > > > > > the capability maintained unless core removes the ability to split > > > > python > > > > packages out. They also remove the *.py files in favor of *.pyo > files > > > > > > (via > > > > > > > a custom packaging mechanism). I have automated tests that go > through > > > > > > the > > > > > > > module importing on each of the meta-python packages to ensure it > works > > > > > > on > > > > > > > minimal python installations. When other contributors don't do > provide > > > > that functionality, I either catch it when I do package update or > when > > > > it > > > > breaks for one of my customers. I'm fine if you don't want to > perform > > > > > > the > > > > > > > checks yourself and it breaks my use case with missing dependencies, > but > > > > > > I > > > > > > > would prefer that you don't remove the dependencies that are > currently > > > > in > > > > place. Thanks. > > > > > > Me too -- some of my projects still use NAND for rootfs, where space is > > > tight and > > > ability to split out python modules is very useful. Thus it is not an > > > unused > > > feature, though many projects have SD/eMMC for rootfs and those ones > > > generally > > > will not care about it. > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* splitting python's standard library 2017-12-18 21:02 ` S. Lockwood-Childs 2017-12-18 21:07 ` Derek Straka @ 2017-12-19 7:56 ` Alexander Kanavin 2017-12-19 12:31 ` Derek Straka 1 sibling, 1 reply; 33+ messages in thread From: Alexander Kanavin @ 2017-12-19 7:56 UTC (permalink / raw) To: S. Lockwood-Childs, Derek Straka, Mark Asselstine, openembeded-devel, Patches and discussions about the oe-core layer On 12/18/2017 11:02 PM, S. Lockwood-Childs wrote: > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: >> I have several customers who have optimized for space and would like to see >> the capability maintained unless core removes the ability to split python >> packages out. They also remove the *.py files in favor of *.pyo files (via >> a custom packaging mechanism). I have automated tests that go through the >> module importing on each of the meta-python packages to ensure it works on >> minimal python installations. When other contributors don't do provide >> that functionality, I either catch it when I do package update or when it >> breaks for one of my customers. I'm fine if you don't want to perform the >> checks yourself and it breaks my use case with missing dependencies, but I >> would prefer that you don't remove the dependencies that are currently in >> place. Thanks. > > Me too -- some of my projects still use NAND for rootfs, where space is tight and > ability to split out python modules is very useful. Thus it is not an unused > feature, though many projects have SD/eMMC for rootfs and those ones generally > will not care about it. This configuration can be supported by making a custom python3-modules package that whitelists precisely the needed files. But it shouldn't be imposed on everyone else - it's a significant burden to maintain the dependencies in every single python package, and keep the splitting working correctly in core python as well. So I'd like to drop that - do keep in mind that very few people maintain oe-core (as opposed to sending occasional drive-by patches to fix specific issues raised in product development), and the headcount keeps getting smaller. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library 2017-12-19 7:56 ` splitting python's standard library Alexander Kanavin @ 2017-12-19 12:31 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-19 12:31 UTC (permalink / raw) To: Alexander Kanavin Cc: S. Lockwood-Childs, openembeded-devel, openembedded-core [-- Attachment #1: Type: text/plain, Size: 2386 bytes --] Well, I've been able to do it just fine for the majority of packages in meta-python by myself. Since I contribute the majority of the patches and maintain the layer, I want this capability maintained in meta-python. If you plan on removing that functionality in oe-core, I'd like to have the opportunity to maintain the python recipes there as well rather than have a feature unilaterally removed. I don't consider it a burden and my customers find it valuable to split things out. On Dec 19, 2017 2:55 AM, "Alexander Kanavin" < alexander.kanavin@linux.intel.com> wrote: On 12/18/2017 11:02 PM, S. Lockwood-Childs wrote: > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > >> I have several customers who have optimized for space and would like to >> see >> the capability maintained unless core removes the ability to split python >> packages out. They also remove the *.py files in favor of *.pyo files >> (via >> a custom packaging mechanism). I have automated tests that go through the >> module importing on each of the meta-python packages to ensure it works on >> minimal python installations. When other contributors don't do provide >> that functionality, I either catch it when I do package update or when it >> breaks for one of my customers. I'm fine if you don't want to perform the >> checks yourself and it breaks my use case with missing dependencies, but I >> would prefer that you don't remove the dependencies that are currently in >> place. Thanks. >> > > Me too -- some of my projects still use NAND for rootfs, where space is > tight and > ability to split out python modules is very useful. Thus it is not an > unused > feature, though many projects have SD/eMMC for rootfs and those ones > generally > will not care about it. > This configuration can be supported by making a custom python3-modules package that whitelists precisely the needed files. But it shouldn't be imposed on everyone else - it's a significant burden to maintain the dependencies in every single python package, and keep the splitting working correctly in core python as well. So I'd like to drop that - do keep in mind that very few people maintain oe-core (as opposed to sending occasional drive-by patches to fix specific issues raised in product development), and the headcount keeps getting smaller. Alex [-- Attachment #2: Type: text/html, Size: 2988 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library @ 2017-12-19 12:31 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-19 12:31 UTC (permalink / raw) To: Alexander Kanavin; +Cc: Mark Asselstine, openembeded-devel, openembedded-core Well, I've been able to do it just fine for the majority of packages in meta-python by myself. Since I contribute the majority of the patches and maintain the layer, I want this capability maintained in meta-python. If you plan on removing that functionality in oe-core, I'd like to have the opportunity to maintain the python recipes there as well rather than have a feature unilaterally removed. I don't consider it a burden and my customers find it valuable to split things out. On Dec 19, 2017 2:55 AM, "Alexander Kanavin" < alexander.kanavin@linux.intel.com> wrote: On 12/18/2017 11:02 PM, S. Lockwood-Childs wrote: > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote: > >> I have several customers who have optimized for space and would like to >> see >> the capability maintained unless core removes the ability to split python >> packages out. They also remove the *.py files in favor of *.pyo files >> (via >> a custom packaging mechanism). I have automated tests that go through the >> module importing on each of the meta-python packages to ensure it works on >> minimal python installations. When other contributors don't do provide >> that functionality, I either catch it when I do package update or when it >> breaks for one of my customers. I'm fine if you don't want to perform the >> checks yourself and it breaks my use case with missing dependencies, but I >> would prefer that you don't remove the dependencies that are currently in >> place. Thanks. >> > > Me too -- some of my projects still use NAND for rootfs, where space is > tight and > ability to split out python modules is very useful. Thus it is not an > unused > feature, though many projects have SD/eMMC for rootfs and those ones > generally > will not care about it. > This configuration can be supported by making a custom python3-modules package that whitelists precisely the needed files. But it shouldn't be imposed on everyone else - it's a significant burden to maintain the dependencies in every single python package, and keep the splitting working correctly in core python as well. So I'd like to drop that - do keep in mind that very few people maintain oe-core (as opposed to sending occasional drive-by patches to fix specific issues raised in product development), and the headcount keeps getting smaller. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library 2017-12-19 12:31 ` Derek Straka @ 2017-12-19 13:12 ` Alexander Kanavin -1 siblings, 0 replies; 33+ messages in thread From: Alexander Kanavin @ 2017-12-19 13:12 UTC (permalink / raw) To: Derek Straka; +Cc: S. Lockwood-Childs, openembeded-devel, openembedded-core On 12/19/2017 02:31 PM, Derek Straka wrote: > Well, I've been able to do it just fine for the majority of packages in > meta-python by myself. Since I contribute the majority of the patches > and maintain the layer, I want this capability maintained in > meta-python. If you plan on removing that functionality in oe-core, I'd > like to have the opportunity to maintain the python recipes there as > well rather than have a feature unilaterally removed. I don't consider > it a burden and my customers find it valuable to split things out. If you're able to take over the maintenance of oe-core's python packages, then that's great and much appreciated! I'll send a patch that assigns them to you in a moment. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library @ 2017-12-19 13:12 ` Alexander Kanavin 0 siblings, 0 replies; 33+ messages in thread From: Alexander Kanavin @ 2017-12-19 13:12 UTC (permalink / raw) To: Derek Straka; +Cc: Mark Asselstine, openembeded-devel, openembedded-core On 12/19/2017 02:31 PM, Derek Straka wrote: > Well, I've been able to do it just fine for the majority of packages in > meta-python by myself. Since I contribute the majority of the patches > and maintain the layer, I want this capability maintained in > meta-python. If you plan on removing that functionality in oe-core, I'd > like to have the opportunity to maintain the python recipes there as > well rather than have a feature unilaterally removed. I don't consider > it a burden and my customers find it valuable to split things out. If you're able to take over the maintenance of oe-core's python packages, then that's great and much appreciated! I'll send a patch that assigns them to you in a moment. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library 2017-12-19 13:12 ` Alexander Kanavin @ 2017-12-19 13:23 ` Derek Straka -1 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-19 13:23 UTC (permalink / raw) To: Alexander Kanavin Cc: S. Lockwood-Childs, openembeded-devel, openembedded-core [-- Attachment #1: Type: text/plain, Size: 905 bytes --] Cool. Works for me. Thanks. -Derek On Tue, Dec 19, 2017 at 8:12 AM, Alexander Kanavin < alexander.kanavin@linux.intel.com> wrote: > On 12/19/2017 02:31 PM, Derek Straka wrote: > >> Well, I've been able to do it just fine for the majority of packages in >> meta-python by myself. Since I contribute the majority of the patches and >> maintain the layer, I want this capability maintained in meta-python. If >> you plan on removing that functionality in oe-core, I'd like to have the >> opportunity to maintain the python recipes there as well rather than have a >> feature unilaterally removed. I don't consider it a burden and my >> customers find it valuable to split things out. >> > > If you're able to take over the maintenance of oe-core's python packages, > then that's great and much appreciated! I'll send a patch that assigns them > to you in a moment. > > Alex > [-- Attachment #2: Type: text/html, Size: 1376 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library @ 2017-12-19 13:23 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-19 13:23 UTC (permalink / raw) To: Alexander Kanavin; +Cc: Mark Asselstine, openembeded-devel, openembedded-core Cool. Works for me. Thanks. -Derek On Tue, Dec 19, 2017 at 8:12 AM, Alexander Kanavin < alexander.kanavin@linux.intel.com> wrote: > On 12/19/2017 02:31 PM, Derek Straka wrote: > >> Well, I've been able to do it just fine for the majority of packages in >> meta-python by myself. Since I contribute the majority of the patches and >> maintain the layer, I want this capability maintained in meta-python. If >> you plan on removing that functionality in oe-core, I'd like to have the >> opportunity to maintain the python recipes there as well rather than have a >> feature unilaterally removed. I don't consider it a burden and my >> customers find it valuable to split things out. >> > > If you're able to take over the maintenance of oe-core's python packages, > then that's great and much appreciated! I'll send a patch that assigns them > to you in a moment. > > Alex > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] splitting python's standard library 2017-12-19 13:23 ` Derek Straka @ 2017-12-19 13:43 ` Burton, Ross -1 siblings, 0 replies; 33+ messages in thread From: Burton, Ross @ 2017-12-19 13:43 UTC (permalink / raw) To: Derek Straka; +Cc: openembeded-devel, openembedded-core [-- Attachment #1: Type: text/plain, Size: 368 bytes --] On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote: > Cool. Works for me. Thanks. > There's an epic patch on the list which I'm reviewing right now that drastically changes how the core Python library is packaged. If you'd like to have a look, the almost-final (my bandaid fixes need to be squashed) is at poky-contrib:ross/py. Ross [-- Attachment #2: Type: text/html, Size: 707 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library @ 2017-12-19 13:43 ` Burton, Ross 0 siblings, 0 replies; 33+ messages in thread From: Burton, Ross @ 2017-12-19 13:43 UTC (permalink / raw) To: Derek Straka; +Cc: Mark Asselstine, openembeded-devel, openembedded-core On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote: > Cool. Works for me. Thanks. > There's an epic patch on the list which I'm reviewing right now that drastically changes how the core Python library is packaged. If you'd like to have a look, the almost-final (my bandaid fixes need to be squashed) is at poky-contrib:ross/py. Ross ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] splitting python's standard library 2017-12-19 13:43 ` Burton, Ross @ 2017-12-19 14:02 ` Derek Straka -1 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-19 14:02 UTC (permalink / raw) To: Burton, Ross; +Cc: openembeded-devel, openembedded-core [-- Attachment #1: Type: text/plain, Size: 628 bytes --] Thanks for the heads up. I'll pull the changeset into my testing branch and touch up all the meta-python recipes to remove the now non-existent packages. On Tue, Dec 19, 2017 at 8:43 AM, Burton, Ross <ross.burton@intel.com> wrote: > On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote: > >> Cool. Works for me. Thanks. >> > > There's an epic patch on the list which I'm reviewing right now that > drastically changes how the core Python library is packaged. If you'd like > to have a look, the almost-final (my bandaid fixes need to be squashed) is > at poky-contrib:ross/py. > > Ross > [-- Attachment #2: Type: text/html, Size: 1343 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library @ 2017-12-19 14:02 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-19 14:02 UTC (permalink / raw) To: Burton, Ross; +Cc: Mark Asselstine, openembeded-devel, openembedded-core Thanks for the heads up. I'll pull the changeset into my testing branch and touch up all the meta-python recipes to remove the now non-existent packages. On Tue, Dec 19, 2017 at 8:43 AM, Burton, Ross <ross.burton@intel.com> wrote: > On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote: > >> Cool. Works for me. Thanks. >> > > There's an epic patch on the list which I'm reviewing right now that > drastically changes how the core Python library is packaged. If you'd like > to have a look, the almost-final (my bandaid fixes need to be squashed) is > at poky-contrib:ross/py. > > Ross > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [oe] splitting python's standard library 2017-12-19 14:02 ` Derek Straka @ 2017-12-28 22:29 ` Derek Straka -1 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-28 22:29 UTC (permalink / raw) To: Burton, Ross; +Cc: openembeded-devel, openembedded-core [-- Attachment #1: Type: text/plain, Size: 998 bytes --] Let me know when this is ready to get merged into master-next. I have a patchset on my github for all the python recipes in meta-oe that need updating based on the deprecated python{3} packages. I can submit it to the ML at that point. Thanks. -Derek On Tue, Dec 19, 2017 at 9:02 AM, Derek Straka <derek@asterius.io> wrote: > Thanks for the heads up. I'll pull the changeset into my testing branch > and touch up all the meta-python recipes to remove the now non-existent > packages. > > On Tue, Dec 19, 2017 at 8:43 AM, Burton, Ross <ross.burton@intel.com> > wrote: > >> On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote: >> >>> Cool. Works for me. Thanks. >>> >> >> There's an epic patch on the list which I'm reviewing right now that >> drastically changes how the core Python library is packaged. If you'd like >> to have a look, the almost-final (my bandaid fixes need to be squashed) is >> at poky-contrib:ross/py. >> >> Ross >> > > [-- Attachment #2: Type: text/html, Size: 2044 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: splitting python's standard library @ 2017-12-28 22:29 ` Derek Straka 0 siblings, 0 replies; 33+ messages in thread From: Derek Straka @ 2017-12-28 22:29 UTC (permalink / raw) To: Burton, Ross; +Cc: Mark Asselstine, openembeded-devel, openembedded-core Let me know when this is ready to get merged into master-next. I have a patchset on my github for all the python recipes in meta-oe that need updating based on the deprecated python{3} packages. I can submit it to the ML at that point. Thanks. -Derek On Tue, Dec 19, 2017 at 9:02 AM, Derek Straka <derek@asterius.io> wrote: > Thanks for the heads up. I'll pull the changeset into my testing branch > and touch up all the meta-python recipes to remove the now non-existent > packages. > > On Tue, Dec 19, 2017 at 8:43 AM, Burton, Ross <ross.burton@intel.com> > wrote: > >> On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote: >> >>> Cool. Works for me. Thanks. >>> >> >> There's an epic patch on the list which I'm reviewing right now that >> drastically changes how the core Python library is packaged. If you'd like >> to have a look, the almost-final (my bandaid fixes need to be squashed) is >> at poky-contrib:ross/py. >> >> Ross >> > > ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2017-12-28 22:29 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-04 19:00 [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22) Mark Asselstine 2017-12-16 21:58 ` Derek Straka 2017-12-18 15:33 ` Mark Asselstine 2017-12-18 15:36 ` Christopher Larson 2017-12-18 16:15 ` Mark Asselstine 2017-12-18 16:37 ` [oe] " Alexander Kanavin 2017-12-18 16:37 ` Alexander Kanavin 2017-12-18 16:56 ` [oe] " Mark Asselstine 2017-12-18 16:56 ` Mark Asselstine 2017-12-18 20:17 ` [oe] " Derek Straka 2017-12-18 20:17 ` Derek Straka 2017-12-18 20:53 ` [oe] " Mark Asselstine 2017-12-18 20:53 ` Mark Asselstine 2017-12-18 21:02 ` S. Lockwood-Childs 2017-12-18 21:07 ` [oe] " Derek Straka 2017-12-18 21:07 ` Derek Straka 2017-12-18 21:26 ` [oe] " Mark Asselstine 2017-12-18 21:26 ` Mark Asselstine 2017-12-18 21:27 ` [oe] " Derek Straka 2017-12-18 21:27 ` Derek Straka 2017-12-19 7:56 ` splitting python's standard library Alexander Kanavin 2017-12-19 12:31 ` Derek Straka 2017-12-19 12:31 ` Derek Straka 2017-12-19 13:12 ` Alexander Kanavin 2017-12-19 13:12 ` Alexander Kanavin 2017-12-19 13:23 ` Derek Straka 2017-12-19 13:23 ` Derek Straka 2017-12-19 13:43 ` [oe] " Burton, Ross 2017-12-19 13:43 ` Burton, Ross 2017-12-19 14:02 ` [oe] " Derek Straka 2017-12-19 14:02 ` Derek Straka 2017-12-28 22:29 ` [oe] " Derek Straka 2017-12-28 22:29 ` Derek Straka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.