Here is the progress for each package.
> csvkit https://github.com/onyxfish/csvkit
Done, just waiting for a new pypi release. See
https://github.com/wireservice/csvkit/issues/20
> django-jinja https://github.com/niwibe/django-jinja
Upstream not interested, claims the
Here is a list of packages that include a test suite on github but not in
the DPMT git.
csvkit https://github.com/onyxfish/csvkit
django-haystackhttps://github.com/toastdriven/django-haystack
django-jinja https://github.com/niwibe/django-jinja
django-recurrence
Tristan Seligmann writes:
> 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
Tristan Seligmann writes:
> 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
Resending to the list since I accidentally replied off-list!
On Thu, 21 Apr 2016, 20:14 Tristan Seligmann,
wrote:
> On Thu, 21 Apr 2016 at 19:34 Barry Warsaw wrote:
>
>> I also don't particularly like relying on GitHub generated tarballs.
>> Despite
On Apr 21, 2016 13:16, "Jeremy Stanley" wrote:
> Agreed, as long as "closely" is interpreted in ways consistent with,
> say, tarballs for C-based projects. Consider `setup.py sdist`
> similar to `make dist` where the dist target of some projects may
> still run additional
On Apr 21, 2016, at 04:52 PM, Thomas Goirand wrote:
>It's best that the test suite goes within the project. So if project is
>called foo, then best is to get the test folder in foo/tests. This way,
>you don't even need to fix the MANIFEST.in.
+1 - as an upstream I always do this because I like
On Apr 21, 2016, at 02:54 PM, Tristan Seligmann 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
On 2016-04-21 11:23:20 -0400 (-0400), Fred Drake wrote:
> On Thu, Apr 21, 2016 at 10:54 AM, Tristan Seligmann
[...]
> > For distribution packaging purposes, the GitHub tags are generally
> > preferrable. GitHub makes archives of tagged releases available as tarballs,
> > so this is generally a
On 04/21/2016 05:20 PM, Matthias Klose wrote:
> On 21.04.2016 16:52, Thomas Goirand wrote:
>> On 04/21/2016 04:10 PM, Edward Betts wrote:
>>> Recently I've come across some Python libraries that have a test
>>> suite in
>>> their github repo but don't include it in the tarball they upload to
>>>
On Thu, Apr 21, 2016 at 11:48 AM, Ian Cordasco
wrote:
> 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,
On Thu, Apr 21, 2016 at 10:23 AM, Fred Drake wrote:
> On Thu, Apr 21, 2016 at 10:54 AM, Tristan Seligmann
> wrote:
>> With my upstream developer hat on: source packages on PyPI are meant for end
>> users to install via pip. They often include generated
On Thu, 21 Apr 2016 at 16:47 Edward Betts wrote:
> Debian binary packages don't normally include the test suite. Some Python
>
library developers are treating the pypi releases in a similar way, as if
> they're just for deployment. They think anybody who needs the test suite
On 04/21/2016 04:10 PM, Edward Betts wrote:
> Recently I've come across some Python libraries that have a test suite in
> their github repo but don't include it in the tarball they upload to pypi.
>
> Debian binary packages don't normally include the test suite.
Why? It's my view that it's a
14 matches
Mail list logo