Quoting Bert, up-thread "Our sdists are pretty big as a result."
Some of my projects have very large test suites that would bloat the
sdist, and I've worked on many more with the same issue. I don't think
we can just wave our hands and say "sdists don't end up particularly
big so we can ignore
On Mon, Sep 10, 2018, at 1:06 PM, Ian Stapleton Cordasco wrote:
> It seems silly that we're not also considering the portions of the
> world with terrible internet when making this decision. Giant sdists
> make their lives orders of magnitude worse for the benefit of maybe
> 20-30 people who tend
And yet reality is that many downstreams can't rely on an sdist to include
that because it is an installable format. Not everything does include those
files. I tend to view an sdist as a similar format to wheels. I've been
bullied into including the tests and docs on occasion, but that has never
As a Nixpkgs Python maintainer I often ask projects to include their tests
in the sdist so we can run them when packaging. I prefer it also when an
sdist basically represents a snapshot of a repository.
On Mon, Sep 10, 2018 at 8:08 AM, Thomas Kluyver
wrote:
> On Mon, Sep 10, 2018, at 12:33 AM,
On Mon, Sep 10, 2018, at 12:33 AM, Bert JW Regeer wrote:
> Speaking as a maintainer of various different packages for the Pylons
> project, we include the following in our sdists:>
> - source code for the package
> - tests for the package
> - documentation for the package
>
> and of course the
I strongly agree with this. I think a lot of the consumers of sdists are people
packaging projects for distributions (fedora, debian, arch, etc), and they want
to run the tests for their package.
I don't install tests for various reasons, including the fact that they are not
part of the public
Bert JW Regeer writes:
> Speaking as a maintainer of various different packages for the Pylons
> project, we include the following in our sdists:
>
> - source code for the package
> - tests for the package
> - documentation for the package
>
> and of course the
Wayne Werner writes:
> It depends on whether or not you require docs or tests with your software.
> Most of the libraries that I've written require neither - nobody is going
> to be running the tests
How can you know that?
If someone wants to try some changes based on the source distribution
Segev Finer writes:
> What should really be included in an sdist via MANIFEST.in?
The ‘sdist’ name is derived from “source distribution (of this Python
package/distribution)”. It is of practical benefit to treat it as “the
state of the source needed for developing this Python distribution, as
I include tests and docs in my sdists, but I don't have the sdist install
them. My goal there is to make it easy for people to grab the sdist, unpack
it, and run the tests/build the docs for their own purposes, without
cluttering up the final environment they install into.
--
Distutils-SIG mailing
Speaking as a maintainer of various different packages for the Pylons project,
we include the following in our sdists:
- source code for the package
- tests for the package
- documentation for the package
and of course the license/history/changelog/everything you'd theoretically need
to create
It depends on whether or not you require docs or tests with your software.
Most of the libraries that I've written require neither - nobody is going
to be running the tests, and if they want the documentation then they're
probably going to check out the library page on readthedocs.
If you had
12 matches
Mail list logo
