Resending to the list since I accidentally replied off-list!

On Thu, 21 Apr 2016, 20:14 Tristan Seligmann, <>

> On Thu, 21 Apr 2016 at 19:34 Barry Warsaw <> wrote:
>> I also don't particularly like relying on GitHub generated tarballs.
>> Despite
>> popular believe, not every upstream uses GH or even git, signs their tags
>> or
>> even tags their releases.  But almost *every* Python package releases
>> tarballs
>> to PyPI.
> There's no particular reason why every Python package has to distribute
> the Debian orig tarball via PyPI, though. *My* projects are almost all on
> GitHub these days, so I offer the git tags and github archives as an option
> to get the "full source"; in the past, I have hosted projects elsewhere,
> and released tarballs elsewhere, and there is of course nothing wrong with
> this.
> If you want to make your PyPI sdists do double-duty, there's usually
> nothing terribly wrong with this, but given that they must include
> generated artifacts (like .c source generated by Cython) in order to work
> well for pip, and pip is typically how people consume PyPI, I don't view
> these as the ideal "upstream source" for Debian.
> And of course, there are extreme examples like *cryptography*: The
> python-cryptography source package is 384K, the python-cryptography-vectors
> source package (necessary for running the cryptography tests) is 26MB!
> FWIW: I should note that I'm a fan of having my tests as a subpackage of
> the main package (ie. mything.tests) so they can be run by an end-user to
> verify that an installed copy of the package is actually working. I do this
> in most of the projects I'm upstream for; so the tests *are* included in
> my sdist, but other files are not (like documentation).

Reply via email to