sampleproject: use tox?
This is a follow up to the thread "Where should I put tests when packaging python modules?" I have never used tox up to now. But reading the mails of the thread, it seems that tox is the current state of the art. This leads me to the conclusion that the sample project should use tox. Any reasons not to do it? Regards, Thomas Güttler -- http://www.thomas-guettler.de/
On Thursday, October 8, 2015, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
This is a follow up to the thread "Where should I put tests when packaging python modules?"
I have never used tox up to now. But reading the mails of the thread, it seems that tox is the current state of the art.
This leads me to the conclusion that the sample project should use tox.
Any reasons not to do it?
In my experience, tox is most useful when developing something that needs to work (and be tested) against multiple Python versions, environments, etc. For projects where the environment is fixed (e.g. an internal application), this isn't necessarily needed. So tox may be an unnecessary addition in those cases. --Chris
Regards, Thomas Güttler
-- http://www.thomas-guettler.de/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org <javascript:;> https://mail.python.org/mailman/listinfo/distutils-sig
On Thu, 8 Oct 2015 22:05:16 +0200 Thomas Güttler <guettliml@thomas-guettler.de> wrote:
This is a follow up to the thread "Where should I put tests when packaging python modules?"
I have never used tox up to now. But reading the mails of the thread, it seems that tox is the current state of the art.
I don't see why that would be the case. tox is certainly "the state of the art" in certain circles, but many projects don't mandate it at all or even don't use it at all and rely on other mechanisms (e.g. CI with a rich configuration matrix). Regards Antoine.
Am 08.10.2015 um 23:33 schrieb Antoine Pitrou:
On Thu, 8 Oct 2015 22:05:16 +0200 Thomas Güttler <guettliml@thomas-guettler.de> wrote:
This is a follow up to the thread "Where should I put tests when packaging python modules?"
I have never used tox up to now. But reading the mails of the thread, it seems that tox is the current state of the art.
I don't see why that would be the case. tox is certainly "the state of the art" in certain circles, but many projects don't mandate it at all or even don't use it at all and rely on other mechanisms (e.g. CI with a rich configuration matrix).
My question was: Any reasons not to use tox in the sample project? I read your answer like this: Many projects don't mandate it at all or even don't use it at all and rely on other mechanisms Yes, it is correct that many projects is a different way. I search a simple guideline for new comers to set up a python project including testing. "Since many projects don't mandate it at all ..." I don't know if this a good argument against it. Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
On 9 October 2015 at 10:32, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
My question was: Any reasons not to use tox in the sample project?
1. Because the sample project is intended to explain how to *package* a project, not how to test it, or document it, or any of a number of other non-packaging things. 2. Because tox is not universally agreed as best practice, and the sample project is intended to demonstrate agreed best practice.
I search a simple guideline for new comers to set up a python project including testing.
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.
On Fri, Oct 9, 2015 at 12:43 PM, Paul Moore <p.f.moore@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? Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
Well, https://packaging.python.org/en/latest/distributing/ already says """ The section does not aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing """ It may be good to add a footnote with your "For more exhaustive examples..." comment - but it would need links, and good luck on getting any sort of agreement on what constitutes good examples :-) Paul On 9 October 2015 at 11:11, Ionel Cristian Mărieș <contact@ionelmc.ro> wrote:
On Fri, Oct 9, 2015 at 12:43 PM, Paul Moore <p.f.moore@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?
Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
On 9 October 2015 at 20:11, Ionel Cristian Mărieș <contact@ionelmc.ro> wrote:
On Fri, Oct 9, 2015 at 12:43 PM, Paul Moore <p.f.moore@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@gmail.com | Brisbane, Australia
On Sat, Oct 10, 2015 at 5:11 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
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.
This begs the conception of yet another opinionated guide for X, Y and Z in Python. I believe we got plenty of those, and what encouraged their creation is exactly this sort of thinking. The problem is that none of them are really comprehensive, well maintained or authoritative enough (we wouldn't have this discussion if there was). They may have been "well-intentioned" but they only create confusion now ... What if there was something official-ish that takes the packaging guide further, for people that want more than just packaging? It seems that there is some demand. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
On Oct 10, 2015 9:55 AM, "Ionel Cristian Mărieș" <contact@ionelmc.ro> wrote:
On Sat, Oct 10, 2015 at 5:11 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
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.
This begs the conception of yet another opinionated guide for X, Y and Z
in Python. I believe we got plenty of those, and what encouraged their creation is exactly this sort of thinking.
The problem is that none of them are really comprehensive, well
maintained or authoritative enough (we wouldn't have this discussion if there was). They may have been "well-intentioned" but they only create confusion now ...
What if there was something official-ish that takes the packaging guide
further, for people that want more than just packaging? It seems that there is some demand. references for such a CreativeWork * http://docs.python-guide.org/en/latest/scenarios/ci/ * https://en.wikipedia.org/wiki/Continuous_integration#Best_practices * http://docs.python-guide.org/en/latest/writing/documentation/ * https://docs.python.org/devguide/documenting.html#sections * http://docs.python-guide.org/en/latest/writing/tests/ * https://packaging.python.org/en/latest/glossary/ * /peps /projects * https://westurner.org/tools/#python-packages * more links above (in this thread) * dox (docker + tox), cookiecutter- * https://westurner.org/tools/#python * https://westurner.org/wiki/awesome-python-testing
Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 9 October 2015 at 09:05, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
This is a follow up to the thread "Where should I put tests when packaging python modules?"
I have never used tox up to now. But reading the mails of the thread, it seems that tox is the current state of the art.
This leads me to the conclusion that the sample project should use tox.
Any reasons not to do it?
Yes, as already said - the sample project is limited in scope to packaging. But in the larger context of 'setting up a Python project from scratch - many folk have written opinionated guides - and if you were writing one of those, even if tox isn't consensus opinion, I'd say use it, so that new folk don't need to read a chunk of prose about choosing the right-thing-for-them. The challenge with education is making the learning curve approachable :) -rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
participants (8)
-
Antoine Pitrou -
Chris Jerdonek -
Ionel Cristian Mărieș -
Nick Coghlan -
Paul Moore -
Robert Collins -
Thomas Güttler -
Wes Turner