| Message ID | 20200824214857.4090659-1-joseph.kogut@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] package/python-pycups: new package | expand |
Hello, On Tue, Aug 25, 2020 at 12:49 AM Joseph Kogut <joseph.kogut@gmail.com> wrote: > > Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com> > --- > DEVELOPERS | 1 + > package/Config.in | 1 + > package/python-pycups/Config.in | 7 +++++++ > package/python-pycups/python-pycups.hash | 5 +++++ > package/python-pycups/python-pycups.mk | 15 +++++++++++++++ > 5 files changed, 29 insertions(+) > create mode 100644 package/python-pycups/Config.in > create mode 100644 package/python-pycups/python-pycups.hash > create mode 100644 package/python-pycups/python-pycups.mk > > diff --git a/DEVELOPERS b/DEVELOPERS > index bba3fd6029..74e05d640a 100644 > --- a/DEVELOPERS > +++ b/DEVELOPERS > @@ -1385,6 +1385,7 @@ F: package/libnss/ > F: package/lld/ > F: package/llvm/ > F: package/python-cython/ > +F: package/python-pycups/ > F: package/python-raven/ > F: package/python-schedule/ > F: package/python-sentry-sdk/ > diff --git a/package/Config.in b/package/Config.in > index d7e79f4795..61a5ec8dc9 100644 > --- a/package/Config.in > +++ b/package/Config.in > @@ -1080,6 +1080,7 @@ menu "External python modules" > source "package/python-pycli/Config.in" > source "package/python-pycparser/Config.in" > source "package/python-pycryptodomex/Config.in" > + source "package/python-pycups/Config.in" > source "package/python-pydal/Config.in" > source "package/python-pydantic/Config.in" > source "package/python-pyelftools/Config.in" > diff --git a/package/python-pycups/Config.in b/package/python-pycups/Config.in > new file mode 100644 > index 0000000000..eeaf70c9e6 > --- /dev/null > +++ b/package/python-pycups/Config.in > @@ -0,0 +1,7 @@ > +config BR2_PACKAGE_PYTHON_PYCUPS According to the README in the repository, Python3 is required for this package so you should add: depends on BR2_PACKAGE_PYTHON3 > + bool "python-pycups" > + depends on BR2_PACKAGE_CUPS Since this package wraps the CUPS API and uses the cups package, you should select BR2_PACKAGE_CUPS instead of depending on it (and add the additional "depends on" sections from cups). > + help > + Python bindings for libcups. > + > + https://github.com/zdohnal/pycups > diff --git a/package/python-pycups/python-pycups.hash b/package/python-pycups/python-pycups.hash > new file mode 100644 > index 0000000000..d1498b61cf > --- /dev/null > +++ b/package/python-pycups/python-pycups.hash > @@ -0,0 +1,5 @@ > +# md5, sha256 from https://pypi.org/pypi/pycups/json > +md5 41eef188b86d01ccfdbaaa05cf0f6ca4 pycups-2.0.1.tar.gz > +sha256 57434ce5f62548eb12949ca8217f066f4eeb21a5d6ab8b13471dce350e380c90 pycups-2.0.1.tar.gz > +# Locally computed sha256 checksums > +sha256 8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643 COPYING > diff --git a/package/python-pycups/python-pycups.mk b/package/python-pycups/python-pycups.mk > new file mode 100644 > index 0000000000..7572040325 > --- /dev/null > +++ b/package/python-pycups/python-pycups.mk > @@ -0,0 +1,15 @@ > +################################################################################ > +# > +# python-pycups > +# > +################################################################################ > + > +PYTHON_PYCUPS_VERSION = 2.0.1 > +PYTHON_PYCUPS_SOURCE = pycups-$(PYTHON_PYCUPS_VERSION).tar.gz > +PYTHON_PYCUPS_SITE = https://files.pythonhosted.org/packages/0c/bb/82546806a86dc16f5eeb76f62ffdc42cce3d43aacd4e25a8b5300eec0263 > +PYTHON_PYCUPS_SETUP_TYPE = distutils > +PYTHON_PYCUPS_LICENSE = GNU General Public License (GPL) GPL is actually a series of licenses, so you should state the specific type. In this case, you can do: PYTHON_PYCUPS_LICENSE = GPL-2.0 > +PYTHON_PYCUPS_LICENSE_FILES = COPYING > +PYTHON_PYCUPS_DEPENDENCIES = cups > + > +$(eval $(python-package)) > -- > 2.28.0 > Best regards, Asaf.
Hello Asaf, Thanks for reviewing! On Tue, 25 Aug 2020 09:41:28 +0300 Asaf Kahlon <asafka7@gmail.com> wrote: > > + bool "python-pycups" > > + depends on BR2_PACKAGE_CUPS > Since this package wraps the CUPS API and uses the cups package, you > should select BR2_PACKAGE_CUPS instead of depending on it (and add the > additional "depends on" sections from cups). I perhaps wouldn't be so strict on this. When a dependency is "obvious", it is quite OK to have a "depends on". In this case, I believe the user who wants python-pycups will realize that CUPS is needed in the system, so I find a "depends on" dependency to be quite OK in this case. Using "depends on" has the advantage that we don't have to replicate the "depends on" from BR2_PACKAGE_CUPS. Thomas
Hello, On Tue, Aug 25, 2020 at 11:08 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Asaf, > > Thanks for reviewing! > > On Tue, 25 Aug 2020 09:41:28 +0300 > Asaf Kahlon <asafka7@gmail.com> wrote: > > > > + bool "python-pycups" > > > + depends on BR2_PACKAGE_CUPS > > Since this package wraps the CUPS API and uses the cups package, you > > should select BR2_PACKAGE_CUPS instead of depending on it (and add the > > additional "depends on" sections from cups). > > I perhaps wouldn't be so strict on this. When a dependency is > "obvious", it is quite OK to have a "depends on". In this case, I > believe the user who wants python-pycups will realize that CUPS is > needed in the system, so I find a "depends on" dependency to be quite > OK in this case. Using "depends on" has the advantage that we don't > have to replicate the "depends on" from BR2_PACKAGE_CUPS. I completely agree that the advantage of this is not duplicating the "depends on" sections. On the other hand: * Differently from other packages that duplicate the "depends on", here we show nothing in case BR2_PACKAGE_CUPS isn't selected, so we should at least add a comment. * In my opinion, even if the user knows that python-pycups needs cups, he wouldn't want to select it on his own and expect it to be selected when choosing python-pycups. But I agree that in some cases it's not so critical. > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Asaf.
On Tue, 25 Aug 2020 13:55:36 +0300 Asaf Kahlon <asafka7@gmail.com> wrote: > On the other hand: > * Differently from other packages that duplicate the "depends on", > here we show nothing in case BR2_PACKAGE_CUPS isn't selected, so we > should at least add a comment. We don't always add a comment when the dependency is obvious. For example, all python-<foo> packages don't have a comment that says "python-<foo> needs python", because it's obvious if you want a Python module that you need to enable Python. > * In my opinion, even if the user knows that python-pycups needs cups, > he wouldn't want to select it on his own and expect it to be selected > when choosing python-pycups. > But I agree that in some cases it's not so critical. I think we agree that there is no clear cut line when it comes to using "depends on" vs. "select" in this sort of situation. What I believe is true is: - We want to use "select" when the dependency is non-obvious, like package "baz" depending on libxml2, openssl and libzorglub. We cannot expect the user to easily figure out those dependencies. - We want to use "depends on" for architecture dependencies/limitations, obviously. - We want to use "depends on" when the user has to be aware of the dependency, or when the dependency cannot easily be lifted. For example dependency on toolchain features: glibc/uclibc/musl, threads, etc. For the other cases, there's no clear cut strategy. But for example cups-filters has a "depends on BR2_PACKAGE_CUPS", with no comment about this because we assume this is obvious. However, all other dependencies of cups-filters are properly enabled using "select" as they are non-obvious. Same for the hplip or gutenprint packages. Thomas
Hello, On Tue, Aug 25, 2020 at 2:07 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Tue, 25 Aug 2020 13:55:36 +0300 > Asaf Kahlon <asafka7@gmail.com> wrote: > > > On the other hand: > > * Differently from other packages that duplicate the "depends on", > > here we show nothing in case BR2_PACKAGE_CUPS isn't selected, so we > > should at least add a comment. > > We don't always add a comment when the dependency is obvious. For > example, all python-<foo> packages don't have a comment that says > "python-<foo> needs python", because it's obvious if you want a Python > module that you need to enable Python. > > > * In my opinion, even if the user knows that python-pycups needs cups, > > he wouldn't want to select it on his own and expect it to be selected > > when choosing python-pycups. > > But I agree that in some cases it's not so critical. > > I think we agree that there is no clear cut line when it comes to using > "depends on" vs. "select" in this sort of situation. > > What I believe is true is: > > - We want to use "select" when the dependency is non-obvious, like > package "baz" depending on libxml2, openssl and libzorglub. We > cannot expect the user to easily figure out those dependencies. > > - We want to use "depends on" for architecture > dependencies/limitations, obviously. > > - We want to use "depends on" when the user has to be aware of the > dependency, or when the dependency cannot easily be lifted. For > example dependency on toolchain features: glibc/uclibc/musl, > threads, etc. Absolutely agree. > > For the other cases, there's no clear cut strategy. But for example > cups-filters has a "depends on BR2_PACKAGE_CUPS", with no comment about > this because we assume this is obvious. However, all other dependencies > of cups-filters are properly enabled using "select" as they are > non-obvious. Same for the hplip or gutenprint packages. I generally agree with the idea, thanks. By the way, there are packages that state the "depends on" part in a comment, like conman-gtk. I personally think it's clearer and doesn't harm, but as you said, there's no clear cut here. > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Asaf.
On Tue, Aug 25, 2020 at 4:29 AM Asaf Kahlon <asafka7@gmail.com> wrote: > > Hello, > > On Tue, Aug 25, 2020 at 2:07 PM Thomas Petazzoni > <thomas.petazzoni@bootlin.com> wrote: > > > > On Tue, 25 Aug 2020 13:55:36 +0300 > > Asaf Kahlon <asafka7@gmail.com> wrote: > > > > > On the other hand: > > > * Differently from other packages that duplicate the "depends on", > > > here we show nothing in case BR2_PACKAGE_CUPS isn't selected, so we > > > should at least add a comment. > > > > We don't always add a comment when the dependency is obvious. For > > example, all python-<foo> packages don't have a comment that says > > "python-<foo> needs python", because it's obvious if you want a Python > > module that you need to enable Python. > > > > > * In my opinion, even if the user knows that python-pycups needs cups, > > > he wouldn't want to select it on his own and expect it to be selected > > > when choosing python-pycups. > > > But I agree that in some cases it's not so critical. > > > > I think we agree that there is no clear cut line when it comes to using > > "depends on" vs. "select" in this sort of situation. > > > > What I believe is true is: > > > > - We want to use "select" when the dependency is non-obvious, like > > package "baz" depending on libxml2, openssl and libzorglub. We > > cannot expect the user to easily figure out those dependencies. > > > > - We want to use "depends on" for architecture > > dependencies/limitations, obviously. > > > > - We want to use "depends on" when the user has to be aware of the > > dependency, or when the dependency cannot easily be lifted. For > > example dependency on toolchain features: glibc/uclibc/musl, > > threads, etc. > Absolutely agree. > > > > > For the other cases, there's no clear cut strategy. But for example > > cups-filters has a "depends on BR2_PACKAGE_CUPS", with no comment about > > this because we assume this is obvious. However, all other dependencies > > of cups-filters are properly enabled using "select" as they are > > non-obvious. Same for the hplip or gutenprint packages. Cups is standalone, cups-filters extends cups with additional functionality, and cups-filters appears in Kconfig menus immediately after cups, making it easy to select at the same time as cups. "Depends on" makes sense here, even without a comment. A Python module wrapping and exposing a C library is a little different. It's in a separate menu from cups, making selection a less obvious process. Some packages such as dbus-python allow a Python API to be built for another package/library by enabling an option next to that package, but my understanding is that these are canonical Python bindings developed and maintained by the parent package's authors. This isn't the case with pycups. I agree with Asaf, If I have an application that depends on pycups, I probably want to just select pycups and all of its dependencies, rather than select cups first, then navigate to a different menu to enable pycups. Cups is implied, as least to the extent that it enables pycups to be built. On the other hand, if I'm building an application that uses a module/library such as pycups, I'd probably write a buildroot package for it that selects the dependencies it needs, rather than navigate through Kconfig menus to select its dependencies. At this point, Buildroot will make it rather obvious that I need to also select cups. When I wrote this package, I hadn't thought that deeply about this. I think both approaches are acceptable, but I'm leaning towards "select" over "depends on" now for this particular package for the reasons stated above. > I generally agree with the idea, thanks. > By the way, there are packages that state the "depends on" part in a > comment, like conman-gtk. > I personally think it's clearer and doesn't harm, but as you said, > there's no clear cut here. > > > > > Thomas > > -- > > Thomas Petazzoni, CTO, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > Asaf.
On Mon, 24 Aug 2020 14:48:57 -0700 Joseph Kogut <joseph.kogut@gmail.com> wrote: > Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com> Applied to master, thanks, with one change. See below. > +PYTHON_PYCUPS_LICENSE = GNU General Public License (GPL) We use SPDX identifiers, so I've changed that to GPL-2.0+, after checking that it was indeed that version of the license. Thanks! Thomas
diff --git a/DEVELOPERS b/DEVELOPERS index bba3fd6029..74e05d640a 100644 --- a/DEVELOPERS +++ b/DEVELOPERS @@ -1385,6 +1385,7 @@ F: package/libnss/ F: package/lld/ F: package/llvm/ F: package/python-cython/ +F: package/python-pycups/ F: package/python-raven/ F: package/python-schedule/ F: package/python-sentry-sdk/ diff --git a/package/Config.in b/package/Config.in index d7e79f4795..61a5ec8dc9 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1080,6 +1080,7 @@ menu "External python modules" source "package/python-pycli/Config.in" source "package/python-pycparser/Config.in" source "package/python-pycryptodomex/Config.in" + source "package/python-pycups/Config.in" source "package/python-pydal/Config.in" source "package/python-pydantic/Config.in" source "package/python-pyelftools/Config.in" diff --git a/package/python-pycups/Config.in b/package/python-pycups/Config.in new file mode 100644 index 0000000000..eeaf70c9e6 --- /dev/null +++ b/package/python-pycups/Config.in @@ -0,0 +1,7 @@ +config BR2_PACKAGE_PYTHON_PYCUPS + bool "python-pycups" + depends on BR2_PACKAGE_CUPS + help + Python bindings for libcups. + + https://github.com/zdohnal/pycups diff --git a/package/python-pycups/python-pycups.hash b/package/python-pycups/python-pycups.hash new file mode 100644 index 0000000000..d1498b61cf --- /dev/null +++ b/package/python-pycups/python-pycups.hash @@ -0,0 +1,5 @@ +# md5, sha256 from https://pypi.org/pypi/pycups/json +md5 41eef188b86d01ccfdbaaa05cf0f6ca4 pycups-2.0.1.tar.gz +sha256 57434ce5f62548eb12949ca8217f066f4eeb21a5d6ab8b13471dce350e380c90 pycups-2.0.1.tar.gz +# Locally computed sha256 checksums +sha256 8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643 COPYING diff --git a/package/python-pycups/python-pycups.mk b/package/python-pycups/python-pycups.mk new file mode 100644 index 0000000000..7572040325 --- /dev/null +++ b/package/python-pycups/python-pycups.mk @@ -0,0 +1,15 @@ +################################################################################ +# +# python-pycups +# +################################################################################ + +PYTHON_PYCUPS_VERSION = 2.0.1 +PYTHON_PYCUPS_SOURCE = pycups-$(PYTHON_PYCUPS_VERSION).tar.gz +PYTHON_PYCUPS_SITE = https://files.pythonhosted.org/packages/0c/bb/82546806a86dc16f5eeb76f62ffdc42cce3d43aacd4e25a8b5300eec0263 +PYTHON_PYCUPS_SETUP_TYPE = distutils +PYTHON_PYCUPS_LICENSE = GNU General Public License (GPL) +PYTHON_PYCUPS_LICENSE_FILES = COPYING +PYTHON_PYCUPS_DEPENDENCIES = cups + +$(eval $(python-package))
Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com> --- DEVELOPERS | 1 + package/Config.in | 1 + package/python-pycups/Config.in | 7 +++++++ package/python-pycups/python-pycups.hash | 5 +++++ package/python-pycups/python-pycups.mk | 15 +++++++++++++++ 5 files changed, 29 insertions(+) create mode 100644 package/python-pycups/Config.in create mode 100644 package/python-pycups/python-pycups.hash create mode 100644 package/python-pycups/python-pycups.mk