Source tarballs from PyPI versus tarballs from the individual project websites

Source tarballs from PyPI versus tarballs from the individual project websites

[Arun Isaac]

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


When packaging python packages, why are we using the source tarballs
hosted on PyPI, rather than using the source tarballs hosted on the
websites of the individual projects?

For example, for the package python-pycrypto, why are we using the
tarball from PyPI
https://pypi.python.org/packages/source/p/pycrypto/pycrypto-2.6.1.tar.gz
instead of the tarball from the pycrypto project website
https://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.6.1.tar.gz ?

Using the PyPI tarball seems to make Guix dependent on another package
repository -- namely, PyPI. That seems to me a bad thing.

I have packaged a few python packages using the tarballs from their
respective project websites. Should I change them to use the PyPI
tarballs before contributing the package definitions to Guix? Which
tarball should I prefer?

Regards,
Arun

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

Re: Source tarballs from PyPI versus tarballs from the individual project websites

[Alex Kost]

Arun Isaac (2016-10-12 11:46 +0530) wrote:

> When packaging python packages, why are we using the source tarballs
> hosted on PyPI, rather than using the source tarballs hosted on the
> websites of the individual projects?
>
> For example, for the package python-pycrypto, why are we using the
> tarball from PyPI
> https://pypi.python.org/packages/source/p/pycrypto/pycrypto-2.6.1.tar.gz
> instead of the tarball from the pycrypto project website
> https://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.6.1.tar.gz ?
>
> Using the PyPI tarball seems to make Guix dependent on another package
> repository -- namely, PyPI. That seems to me a bad thing.
>
> I have packaged a few python packages using the tarballs from their
> respective project websites. Should I change them to use the PyPI
> tarballs before contributing the package definitions to Guix? Which
> tarball should I prefer?

As for me, I always prefer tarballs directly from the upstream.  So I
wouldn't change those packages to use PyPi sources.

-- 
Alex

Re: Source tarballs from PyPI versus tarballs from the individual project websites

[Christopher Allan Webber]

Arun Isaac writes:

> When packaging python packages, why are we using the source tarballs
> hosted on PyPI, rather than using the source tarballs hosted on the
> websites of the individual projects?
>
> For example, for the package python-pycrypto, why are we using the
> tarball from PyPI
> https://pypi.python.org/packages/source/p/pycrypto/pycrypto-2.6.1.tar.gz
> instead of the tarball from the pycrypto project website
> https://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.6.1.tar.gz ?

The easy answer is probably "the importer tool we have makes it easy to
pull the version down from PyPI", so that's the way most of us package
it.

I'd be for using actual upstream, or at least supplying both, so that
they're mirrors.  One concern is, what about the tooling for telling us
when updates to packages are available?

 - Chris

Re: Source tarballs from PyPI versus tarballs from the individual project websites

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> I'd be for using actual upstream, or at least supplying both, so that
> they're mirrors.  One concern is, what about the tooling for telling us
> when updates to packages are available?

‘guix refresh’ works for PyPI but not for arbitrary sites.

That would be in favor of using PyPI as the source, but I don’t know
what else is at stake.

Ludo’.

Re: Source tarballs from PyPI versus tarballs from the individual project websites

[Arun Isaac]

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


>> One concern is, what about the tooling for telling us when updates to
>> packages are available?
>
> ‘guix refresh’ works for PyPI but not for arbitrary sites.

Why not let 'guix refresh' use PyPI to detect package updates, and then
let somebody manually find the equivalent upstream tarball URI and put
it in the package definition?

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

Re: Source tarballs from PyPI versus tarballs from the individual project websites

[Ludovic Courtès]

Arun Isaac <arunisaac@systemreboot.net> skribis:

>>> One concern is, what about the tooling for telling us when updates to
>>> packages are available?
>>
>> ‘guix refresh’ works for PyPI but not for arbitrary sites.
>
> Why not let 'guix refresh' use PyPI to detect package updates, and then
> let somebody manually find the equivalent upstream tarball URI and put
> it in the package definition?

The problem is that the PyPI “updater” that ‘guix refresh’ uses needs to
be able to determine that a package is a “PyPI package”, which is what
the ‘pypi-package?’ predicate in (guix import pypi) does.  If a package
uses a URL other than pypi.python.org, that predicate returns false.

Ludo’.

Re: Source tarballs from PyPI versus tarballs from the individual project websites

[Leo Famulari]

On Wed, Oct 12, 2016 at 06:57:28AM -0500, Christopher Allan Webber wrote:
> I'd be for using actual upstream, or at least supplying both, so that
> they're mirrors.  One concern is, what about the tooling for telling us
> when updates to packages are available?

I've noticed that the PyPi tarballs and the "upstream site" tarballs are
usually not the same thing. So, you could ask upstream what the prefer
packagers use and pick that one.