Re: Test suite in github but missing from pypi tarballs
On Thu, Apr 21, 2016 at 10:23 AM, Fred Drake <fred@fdrake.net> wrote:
> On Thu, Apr 21, 2016 at 10:54 AM, Tristan Seligmann
> <mithrandi@mithrandi.net> wrote:
>> With my upstream developer hat on: source packages on PyPI are meant for end
>> users to install via pip. They often include generated artifacts, and don't
>> include things that aren't intended for installation via pip (tests being
>> just one of these).
>
> Interesting. In many years of working with Python (since before
> either PyPI or pip), I have a slightly different perspective.
>
> Source packages (whether on PyPI or not) with a setup.py (or whatever
> comes next) are intended for both automated or developer consumption.
> pip is just one possible tool; buildout is another, and others as
> well.
In the long history of both Python and its packaging this is
absolutely true (all you need is an archive and a setup.py) but
Python's packaging has evolved and improved for its users through
setuptools, pip, and wheel (even though I'm sure there are many on
this list who vehemently disagree). So tar files, for the *majority*
of PyPI are there to help users with ancient, barely working, versions
of pip, buildout, etc.
>> For distribution packaging purposes, the GitHub tags are generally
>> preferrable. GitHub makes archives of tagged releases available as tarballs,
>> so this is generally a simple tweak to debian/watch.
>
> I'd generally be worried if the source package doesn't closely match a
> tag in whatever VCS a project is using, but I don't think that's
> essential, release processes being what they are.
There's also a lot of data that could be in a VCS tag that is
orthogonal to what needs to be in a package for a user or
redistributor. For example, few if any people are going to want a file
that configures the (potentially closed-source) continuous integration
service(s) that the project uses and it's inconsequential to a
redistributor if a .gitignore is in the archive too. Some of this will
just needlessly inflate the package size.
> This is really independent from the debate as to whether a test suite
> should be included with the package, though.
Agreed. It's just interesting.
Reply to: