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 t
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 of these).
>
> For distribu
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 of these).
>
> For distribu
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
>> popular believe, not every upstream uses G
Fred Drake writes:
> My reaction is really about the comment that source packages are in
> PyPI "for pip". You definitely understand that it's broader than that,
> but careful language is important to avoid confusing someone new,
> leading to poor understanding across the community.
>
> Some of u
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 commands to generate meta
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 ha
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 simp
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
>>> py
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, and wheel (even though I'm s
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 artifacts, and don't
>> include things that
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 artifacts, and don't
> include things that aren't intended for installation via pip (tests being
> just
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 pypi.
Debian binary packages don't normally include the test suit
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 is
> doing developmen
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 good
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. Some Python
library developers are treating the pypi releases in a similar way, as if
t
18 matches
Mail list logo
