diff mbox series

[1/1] package/python-pycups: new package

Message ID 20200824214857.4090659-1-joseph.kogut@gmail.com
State New
Headers show
Series [1/1] package/python-pycups: new package | expand

Commit Message

Joseph Kogut Aug. 24, 2020, 9:48 p.m. UTC
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

Comments

Asaf Kahlon Aug. 25, 2020, 6:41 a.m. UTC | #1
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.
Thomas Petazzoni Aug. 25, 2020, 8:08 a.m. UTC | #2
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
Asaf Kahlon Aug. 25, 2020, 10:55 a.m. UTC | #3
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.
Thomas Petazzoni Aug. 25, 2020, 11:07 a.m. UTC | #4
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
Asaf Kahlon Aug. 25, 2020, 11:29 a.m. UTC | #5
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.
Joseph Kogut Aug. 25, 2020, 11:14 p.m. UTC | #6
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.
diff mbox series

Patch

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))