bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Alex Griffin]

[-- Attachment #1: Type: text/plain, Size: 69 bytes --]

This patch updates asciinema to the latest version.
-- 
Alex Griffin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-asciinema-Update-to-1.4.0.patch --]
[-- Type: text/x-patch; name="0001-gnu-asciinema-Update-to-1.4.0.patch", Size: 1809 bytes --]

From 4d0e4cc34724acdae41804e8e8f9eaed9e625ffc Mon Sep 17 00:00:00 2001
From: Alex Griffin <a@ajgrf.com>
Date: Sat, 27 May 2017 09:57:19 -0500
Subject: [PATCH] gnu: asciinema: Update to 1.4.0.

* gnu/packages/terminals.scm (asciinema): Update to 1.4.0.
[source]: Use pypi-uri.
---
 gnu/packages/terminals.scm | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index a8007586c..028cc99bf 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015, 2016 Efraim Flashner <efraim@flashner.co.il>
 ;;; Copyright © 2016 Mckinley Olsen <mck.olsen@gmail.com>
-;;; Copyright © 2016 Alex Griffin <a@ajgrf.com>
+;;; Copyright © 2016, 2017 Alex Griffin <a@ajgrf.com>
 ;;; Copyright © 2016 David Craven <david@craven.ch>
 ;;; Copyright © 2016 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2016, 2017 José Miguel Sánchez García <jmi2k@openmailbox.org>
@@ -146,17 +146,14 @@ insert mode and command mode where keybindings have different functions.")
 (define-public asciinema
   (package
     (name "asciinema")
-    (version "1.3.0")
+    (version "1.4.0")
     (source
      (origin
        (method url-fetch)
-       (uri (string-append
-             "https://pypi.python.org/packages/06/96/93947d9be78aebb7985014fdf"
-             "4d84896dd0f62514d922ee03f5bb55a21fb/asciinema-" version
-             ".tar.gz"))
+       (uri (pypi-uri "asciinema" version))
        (sha256
         (base32
-         "1crdm9zfdbjflvz1gsqvy5zsbgwdfkj34z69kg6h5by70rrs1hdc"))))
+         "1jrf8c8711gkdilmvyv3d37kp8xfvdc5cqighw5k92a6g9z4acgv"))))
     (build-system python-build-system)
     (arguments
      `(#:phases
-- 
2.13.0

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Arun Isaac]

Thanks for the patch!

> * gnu/packages/terminals.scm (asciinema): Update to 1.4.0.
> [source]: Use pypi-uri.

Could you switch to upstream's github release tarball instead?
https://github.com/asciinema/asciinema/archive/v1.4.0.tar.gz

LGTM, otherwise!

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Sun, May 28, 2017 at 10:30:34PM +0530, Arun Isaac wrote:
> 
> Thanks for the patch!
> 
> > * gnu/packages/terminals.scm (asciinema): Update to 1.4.0.
> > [source]: Use pypi-uri.
> 
> Could you switch to upstream's github release tarball instead?
> https://github.com/asciinema/asciinema/archive/v1.4.0.tar.gz
> 
> LGTM, otherwise!

Is there a reason to prefer one over the other?

I ask because, typically, these unammed GitHub tarballs are not actual
releases prepared by the maintainers, but just a snapshot of the Git
repo, created automatically by GitHub for each tag. PyPi tends to
contain the "real" release in cases like this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Arun Isaac]

>> Could you switch to upstream's github release tarball instead?
>> https://github.com/asciinema/asciinema/archive/v1.4.0.tar.gz
>>
>> LGTM, otherwise!
>
> Is there a reason to prefer one over the other?
>
> I ask because, typically, these unammed GitHub tarballs are not actual
> releases prepared by the maintainers, but just a snapshot of the Git
> repo, created automatically by GitHub for each tag. PyPi tends to
> contain the "real" release in cases like this.

I thought it is better to depend directly on the upstream source
(github, in this case) than on an intermediary (pypi) who has also
packaged the software. If we use pypi, Guix becomes some kind of second
order package repository that depends on pypi, the primary package
repository. WDYT?

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Mon, May 29, 2017 at 03:48:36AM +0530, Arun Isaac wrote:
> 
> >> Could you switch to upstream's github release tarball instead?
> >> https://github.com/asciinema/asciinema/archive/v1.4.0.tar.gz
> >>
> >> LGTM, otherwise!
> >
> > Is there a reason to prefer one over the other?
> >
> > I ask because, typically, these unammed GitHub tarballs are not actual
> > releases prepared by the maintainers, but just a snapshot of the Git
> > repo, created automatically by GitHub for each tag. PyPi tends to
> > contain the "real" release in cases like this.
> 
> I thought it is better to depend directly on the upstream source
> (github, in this case) than on an intermediary (pypi) who has also
> packaged the software. If we use pypi, Guix becomes some kind of second
> order package repository that depends on pypi, the primary package
> repository. WDYT?

My understanding is that project maintainers upload their releases to
PyPi, not that PyPi packages the release for them. Is that incorrect?

The GitHub tarballs that are named like 'v$version.tar.gz' are not
releases made by the upstream projects. Take flex as an example:

https://github.com/westes/flex/releases/tag/v2.6.4

The file 'flex-2.6.4.tar.gz' is a release tarball prepared by the flex
maintainer.

The link to 'Source code (tar.gz)' leads to 'v2.6.4.tar.gz', which is a
snapshot of the tagged commit, created automatically by GitHub. It's not
prepared by the maintainer, and it can't be built in the normal way
because it hasn't been bootstrapped. It may be missing things like
special documentation, NEWS, etc. Also, there may be extraneous
development files included in the snapshot.

In general, I think we should avoid the GitHub snapshots unless there is
nothing else to use. In this case, is there something wrong with the
release uploaded to PyPi?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Mon, May 29, 2017 at 03:48:36AM +0530, Arun Isaac wrote:
>> 
>> >> Could you switch to upstream's github release tarball instead?
>> >> https://github.com/asciinema/asciinema/archive/v1.4.0.tar.gz
>> >>
>> >> LGTM, otherwise!
>> >
>> > Is there a reason to prefer one over the other?
>> >
>> > I ask because, typically, these unammed GitHub tarballs are not actual
>> > releases prepared by the maintainers, but just a snapshot of the Git
>> > repo, created automatically by GitHub for each tag. PyPi tends to
>> > contain the "real" release in cases like this.
>> 
>> I thought it is better to depend directly on the upstream source
>> (github, in this case) than on an intermediary (pypi) who has also
>> packaged the software. If we use pypi, Guix becomes some kind of second
>> order package repository that depends on pypi, the primary package
>> repository. WDYT?
>
> My understanding is that project maintainers upload their releases to
> PyPi, not that PyPi packages the release for them. Is that incorrect?

This is true. The PyPi releases are often different from the raw
sources, look for the magic lines "packages" and "package_data" in
setup.py[0] to see what is included/excluded in the PyPi archive.
Unfortunately some packages also exlude tests, in which case it's okay
to use the upstream repository.

Some projects provide PGP signatures on PyPi as well, which is great.
Take matplotlib for example:

https://pypi.python.org/pypi/matplotlib (PGP signed tarball, 52MiB)
https://github.com/matplotlib/matplotlib/releases (no signature, 51MiB)

[0] https://packaging.python.org/distributing/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Arun Isaac]

Marius Bakke writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Mon, May 29, 2017 at 03:48:36AM +0530, Arun Isaac wrote:
>>> 
>>> >> Could you switch to upstream's github release tarball instead?
>>> >> https://github.com/asciinema/asciinema/archive/v1.4.0.tar.gz
>>> >>
>>> >> LGTM, otherwise!
>>> >
>>> > Is there a reason to prefer one over the other?
>>> >
>>> > I ask because, typically, these unammed GitHub tarballs are not actual
>>> > releases prepared by the maintainers, but just a snapshot of the Git
>>> > repo, created automatically by GitHub for each tag. PyPi tends to
>>> > contain the "real" release in cases like this.
>>> 
>>> I thought it is better to depend directly on the upstream source
>>> (github, in this case) than on an intermediary (pypi) who has also
>>> packaged the software. If we use pypi, Guix becomes some kind of second
>>> order package repository that depends on pypi, the primary package
>>> repository. WDYT?
>>
>> My understanding is that project maintainers upload their releases to
>> PyPi, not that PyPi packages the release for them. Is that incorrect?
>
> This is true. The PyPi releases are often different from the raw
> sources, look for the magic lines "packages" and "package_data" in
> setup.py[0] to see what is included/excluded in the PyPi archive.
> Unfortunately some packages also exlude tests, in which case it's okay
> to use the upstream repository.
>
> Some projects provide PGP signatures on PyPi as well, which is great.
> Take matplotlib for example:
>
> https://pypi.python.org/pypi/matplotlib (PGP signed tarball, 52MiB)
> https://github.com/matplotlib/matplotlib/releases (no signature, 51MiB)
>
> [0] https://packaging.python.org/distributing/

Ok, we'll use the pypi tarball, then. I'm building something else
now. Once I'm done, I'll build asciinema, verify, and push.

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Arun Isaac]

Pushed! :-)

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Arun Isaac]

Marius Bakke writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> My understanding is that project maintainers upload their releases to
>> PyPi, not that PyPi packages the release for them. Is that incorrect?
>
> This is true. The PyPi releases are often different from the raw
> sources, look for the magic lines "packages" and "package_data" in
> setup.py[0] to see what is included/excluded in the PyPi archive.
> Unfortunately some packages also exlude tests, in which case it's okay
> to use the upstream repository.
>
> Some projects provide PGP signatures on PyPi as well, which is great.
> Take matplotlib for example:
>
> https://pypi.python.org/pypi/matplotlib (PGP signed tarball, 52MiB)
> https://github.com/matplotlib/matplotlib/releases (no signature, 51MiB)
>
> [0] https://packaging.python.org/distributing/

In general, for the typical python library/package (published both on
pypi and github), should we prefer the pypi tarball or the original
upstream github tarball? WDYT?

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Tue, May 30, 2017 at 12:53:04AM +0530, Arun Isaac wrote:
> In general, for the typical python library/package (published both on
> pypi and github), should we prefer the pypi tarball or the original
> upstream github tarball? WDYT?

In my experience, it seems like the PyPi tarballs are what the upstream
projects want distributors to use.

However, as Marius pointed out, sometimes the upstream projects choose
not to distribute their tests on PyPi, and in that case I like to use
whichever release has tests, since the tests help us be sure that our
packaging works.

So, I usually use what's on PyPi, but it depends.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Arun Isaac]

> In my experience, it seems like the PyPi tarballs are what the upstream
> projects want distributors to use.
>
> So, I usually use what's on PyPi, but it depends.

By preferring pypi, I worry that we promote a kind of centralization. In
my romanticized vision for the future, I see every one self-hosting
their own servers, serving code for their projects, and guix pulling and
building from all of them. This is why I find excessive dependence on
pypi disturbing. We are also creating a single point of failure/attack
at pypi. Granted that everyone using github to host their projects is
not much better, still...

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

Arun Isaac <arunisaac@systemreboot.net> writes:

>> In my experience, it seems like the PyPi tarballs are what the upstream
>> projects want distributors to use.
>>
>> So, I usually use what's on PyPi, but it depends.
>
> By preferring pypi, I worry that we promote a kind of centralization. In
> my romanticized vision for the future, I see every one self-hosting
> their own servers, serving code for their projects, and guix pulling and
> building from all of them. This is why I find excessive dependence on
> pypi disturbing. We are also creating a single point of failure/attack
> at pypi. Granted that everyone using github to host their projects is
> not much better, still...

I don't find Github better at all. One is a centralized source code
hosting platform, the other is a centralized Python package publishing
platform.

In the rare case where the package is hosted elsewhere (e.g. on a
personal/project home page) then we should use that*, but I have no
real preference between github/bitbucket/etc and PyPi other than
PyPi packages often being more "polished".

* Usually**, such pages just link to PyPi.
** See "python-cram" for a counter-example.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#27110: [PATCH] gnu: asciinema: Update to 1.4.0.

[Arun Isaac]

Marius Bakke writes:

> I don't find Github better at all. One is a centralized source code
> hosting platform, the other is a centralized Python package publishing
> platform.

Agreed.

> In the rare case where the package is hosted elsewhere (e.g. on a
> personal/project home page) then we should use that

Fair enough... This is an acceptable strategy.