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

[Arun Isaac]

Marius Bakke writes:

> Leo Famulari <address@hidden> 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.