[Distutils] sampleproject: use tox?

[Nick Coghlan]

On 9 October 2015 at 20:11, Ionel Cristian Mărieș <contact at ionelmc.ro> wrote:
>
> On Fri, Oct 9, 2015 at 12:43 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>>
>> The sample project is not intended for that purpose. It's a good
>> starting point for something like that, but that's not its purpose.
>>
>> Paul
>>
>> PS I sympathise with your wish for a "do this to set up your first
>> project" beginner's guide. I've wanted one of those myself for a long
>> time now. But I don't believe such a thing exists, unfortunately.
>
> Should we at least give some pointers as to what people should look at for a
> fully fledged project? Like a lists with examples/templates covering all the
> variants. Eg:
>
> "PyPA's sample projects only covers the packaging aspect of a project. For
> more exhaustive examples take a look at cookiecutter templates, barry's
> sample, ogrisel's appveyor demo, this and that etc etc"
>
> How about something like that?

This unfortunately isn't a good idea, at least for folks aiming to
publish their first project. While it's well-intentioned, the problem
with it is that it can be *tremendously* demotivating for folks that
aren't already familiar with all those additional niceties, as it hits
newcomers over the head with how much they still have to learn.
Testing in particular is problematic, as writing tests involves
writing programs about programs. That means you need to already
understand a fair bit about programs *and* about how programs fail, to
appreciate why it may make sense to write a second program to make
sure the first program is behaving as you expect. Folks that already
have that knowledge aren't going to need the packaging guide to tell
them how to do it, while folks that don't have that knowledge are
going to be confused by a digression on testing and documentation when
they're wanting to learn about packaging and distribution.

That said, what might be interesting is to have a section in the
packaging user guide that talks about "The second release", as
*that's* where the value of things like testing ("How do you know that
everything you published the first time still works?") and semantic
versioning ("How do your users know whether or not your API is
stable?") start to make more sense.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia