Patchwork gnu: Add python-xopen.

login
register
mail settings
Submitter Tobias Geerinckx-Rice
Date Dec. 14, 2016, 10:57 p.m.
Message ID <20161214225712.31168-1-me@tobias.gr>
Download mbox | patch
Permalink /patch/18468/
State New
Headers show

Comments

Tobias Geerinckx-Rice - Dec. 14, 2016, 10:57 p.m.
* gnu/packages/python.scm (python-xopen, python2-xopen): New variables.
---
 gnu/packages/python.scm | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
Marius Bakke - Dec. 15, 2016, 9:20 a.m.
Tobias Geerinckx-Rice <me@tobias.gr> writes:

> * gnu/packages/python.scm (python-xopen, python2-xopen): New variables.
> ---
>  gnu/packages/python.scm | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index 789e199..70c5aed 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -11929,3 +11929,29 @@ network.")
>  
>  (define-public python2-argcomplete
>    (package-with-python2 python-argcomplete))
> +
> +(define-public python-xopen
> +  (package
> +    (name "python-xopen")
> +    (version "0.1.1")
> +    (source
> +      (origin
> +        (method url-fetch)
> +        (uri (string-append "https://github.com/marcelm/xopen/archive/v"
> +                            version ".tar.gz"))

Why not use 'pypi-uri' here? Otherwise LGTM.

> +        (sha256
> +          (base32
> +           "1dp0fg56fk5kiz9n1h82b6bf9vf15p4c79bvidlbgvsx3jqqaa39"))
> +        (file-name (string-append name "-" version ".tar.gz"))))
> +    (build-system python-build-system)
> +    (home-page "https://github.com/marcelm/xopen/")
> +    (synopsis "Open compressed files transparently")
> +    (description "This module provides an @code{xopen} function that works like
> +Python's built-in @code{open} function, but can also deal with compressed files.
> +Supported compression formats are gzip, bzip2 and, xz, and are automatically
> +recognized by their file extensions.  The focus is on being as efficient as
> +possible on all supported Python versions.")
> +    (license license:expat)))
> +
> +(define-public python2-xopen
> +  (package-with-python2 python-xopen))
> -- 
> 2.9.3
Tobias Geerinckx-Rice - Dec. 15, 2016, 10:02 a.m.
Marius,

On 15/12/16 10:20, Marius Bakke wrote:
> Why not use 'pypi-uri' here? Otherwise LGTM.

What would that give us?

Thanks,

T G-R
Marius Bakke - Dec. 16, 2016, 4:09 p.m.
Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Marius,
>
> On 15/12/16 10:20, Marius Bakke wrote:
>> Why not use 'pypi-uri' here? Otherwise LGTM.
>
> What would that give us?

Good question. Pypi archives are sometimes smaller than the raw sources
or otherwise "prepared", but I guess no inherent benefits.
Leo Famulari - Dec. 16, 2016, 8:19 p.m.
On Thu, Dec 15, 2016 at 11:02:29AM +0100, Tobias Geerinckx-Rice wrote:
> Marius,
> 
> On 15/12/16 10:20, Marius Bakke wrote:
> > Why not use 'pypi-uri' here? Otherwise LGTM.
> 
> What would that give us?

From what I can tell, GitHub automatically generates snapshot tarballs
of Git tags. These tarballs are usually not real "release" tarballs that
have been prepared by the upstream maintainers. Sometimes this isn't the
case, but it seems to be for these "untitled" v$version.tar.gz tarballs.

We have tools to automatically update packages fetched from PyPi.

And using pypi-uri removes another URL that we need to maintain.

Is there a reason not to use PyPi?
Tobias Geerinckx-Rice - Dec. 18, 2016, 1 a.m.
Marius,

On 16/12/16 17:09, Marius Bakke wrote:
> Pypi archives are sometimes smaller than the raw sources

Oh, I didn't know that.

> or otherwise "prepared", but I guess no inherent benefits.

Good point. I can certainly see people relying too heavily on GitHub
(and similar) tarball auto-generation, while uploading a better one to
PyPI that they've actually bootstrapped.

Since this one builds fine, and the GitHub project is the official home
page for better or worse, I'd vote against adding an ‘additional
dependency on PyPI infrastucture’ as I think someone on the list put it.

A glance at the Guix commit log suggests you're far more knowledgable
than I about anything Python, though.

Kind regards,

T G-R
Ben Woodcroft - Dec. 18, 2016, 1:23 a.m.
On 18/12/16 11:00, Tobias Geerinckx-Rice wrote:
> Marius,
>
> On 16/12/16 17:09, Marius Bakke wrote:
>> Pypi archives are sometimes smaller than the raw sources
> Oh, I didn't know that.
>
>> or otherwise "prepared", but I guess no inherent benefits.
> Good point. I can certainly see people relying too heavily on GitHub
> (and similar) tarball auto-generation, while uploading a better one to
> PyPI that they've actually bootstrapped.
>
> Since this one builds fine, and the GitHub project is the official home
> page for better or worse, I'd vote against adding an ‘additional
> dependency on PyPI infrastucture’ as I think someone on the list put it.

Another reason for using pypi is that the github updater ignores tagged 
but not released 'releases', such as this. Perhaps we should change 
that, do others have an opinion?

Since using pypi is the way Python users expect to be able to install 
packages, making developers less concerned about their github releases 
than their pypi ones, I reckon sticking with pypi-uri is the way to go.

ben
Hartmut Goebel - Dec. 18, 2016, 10:07 a.m.
Am 18.12.2016 um 02:23 schrieb Ben Woodcroft:
> Since using pypi is the way Python users expect to be able to install
> packages, making developers less concerned about their github releases
> than their pypi ones, I reckon sticking with pypi-uri is the way to go. 

+1
Tobias Geerinckx-Rice - Dec. 18, 2016, 4:21 p.m.
Ben, Guix,

On 18/12/16 02:23, Ben Woodcroft wrote:
> Since using pypi is the way Python users expect to be able to install
> packages, making developers less concerned about their github releases
> than their pypi ones, I reckon sticking with pypi-uri is the way to go.

I'm not a Python programmer and have never used PyPI. The one time I did
try to use it as a one-stop update shop, it turned out to be out-of-date.

I'll adjust accordingly and push. Thanks (everyone) for the useful
feed-back!

Kind regards,

T G-R

Patch

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 789e199..70c5aed 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -11929,3 +11929,29 @@  network.")
 
 (define-public python2-argcomplete
   (package-with-python2 python-argcomplete))
+
+(define-public python-xopen
+  (package
+    (name "python-xopen")
+    (version "0.1.1")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (string-append "https://github.com/marcelm/xopen/archive/v"
+                            version ".tar.gz"))
+        (sha256
+          (base32
+           "1dp0fg56fk5kiz9n1h82b6bf9vf15p4c79bvidlbgvsx3jqqaa39"))
+        (file-name (string-append name "-" version ".tar.gz"))))
+    (build-system python-build-system)
+    (home-page "https://github.com/marcelm/xopen/")
+    (synopsis "Open compressed files transparently")
+    (description "This module provides an @code{xopen} function that works like
+Python's built-in @code{open} function, but can also deal with compressed files.
+Supported compression formats are gzip, bzip2 and, xz, and are automatically
+recognized by their file extensions.  The focus is on being as efficient as
+possible on all supported Python versions.")
+    (license license:expat)))
+
+(define-public python2-xopen
+  (package-with-python2 python-xopen))