Re: [cctbxbb] Native python unittests for the libtbx testing framework
Am Freitag 15 Mai 2015 18:07:33 schrieb Pavel Afonine:
Hi Markus,
lucky you, I wish I have time for side projects!
I've been working on cctbx (and writing tests!) for the past 12 years and can't name any problem using "libtbx testing world". Most tests are written this way. Why I am not so keen to use an alternative? - why introduce inconsistency for no obvious clear pressing reasons; - I have no spare time to learn and get used to an alternative framework (again, for no obvious clear pressing reason); - some rare developers (mostly postdocs that come and go) used Python test framework in the past on the code that I work too and that I have to maintain when people are gone. I find it is an irritating overhead for me dealing with these tests, so typically I bother to re-write them to use libtbx tools.
Hi Pavel, those are sound and valid reasons from your point of view. But please also consider this alternative view: Coming from other python projects people are likely to have experience with the python unit test framework. As cctbx is using its own testing functionality people might be put off from writing tests or at least have to overcome this additional barrier on entry. I'm a strong supporter of sticking/moving to standards like PEP0008 [1] or pip/whl* based installs as conforming to those helps people to quickly find their way into the code. * wouldn't it be great if one could simply tell people this: "To install cctbx simply type 'pip install cctbx' in your terminal."? [1] https://www.python.org/dev/peps/pep-0008/ With regards, Dipl. Phys. Jan M. Simons Institute of Crystallography RWTH Aachen University
HI All, I would like to echo these comments - there are times when cctbx can feel "different at any cost" which continually makes it harder to encourage people to adopt it as a basis for doing methods development. We should welcome opportunities to make things more pythonic when they do not break what we have at the moment. The testing is one such example. I appreciate that many of the "differences" are for a real reason, but equally saying "we don't do python unit tests, we do it *our* way" could easily be interpreted as being ... unhelpful ... to the new user or developer. I for one want these people to contribute to the project and make it better! Here at Diamond we have completely committed to using cctbx for a really rather large range of things, but even so persuading other people here to also use it is harder than it really needs to be. Installation complexity is just one reason... Best wishes Graeme -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jan Marten Simons Sent: 19 May 2015 11:22 To: cctbx mailing list Subject: Re: [cctbxbb] Native python unittests for the libtbx testing framework Am Freitag 15 Mai 2015 18:07:33 schrieb Pavel Afonine:
Hi Markus,
lucky you, I wish I have time for side projects!
I've been working on cctbx (and writing tests!) for the past 12 years and can't name any problem using "libtbx testing world". Most tests are written this way. Why I am not so keen to use an alternative? - why introduce inconsistency for no obvious clear pressing reasons; - I have no spare time to learn and get used to an alternative framework (again, for no obvious clear pressing reason); - some rare developers (mostly postdocs that come and go) used Python test framework in the past on the code that I work too and that I have to maintain when people are gone. I find it is an irritating overhead for me dealing with these tests, so typically I bother to re-write them to use libtbx tools.
Hi Pavel, those are sound and valid reasons from your point of view. But please also consider this alternative view: Coming from other python projects people are likely to have experience with the python unit test framework. As cctbx is using its own testing functionality people might be put off from writing tests or at least have to overcome this additional barrier on entry. I'm a strong supporter of sticking/moving to standards like PEP0008 [1] or pip/whl* based installs as conforming to those helps people to quickly find their way into the code. * wouldn't it be great if one could simply tell people this: "To install cctbx simply type 'pip install cctbx' in your terminal."? [1] https://www.python.org/dev/peps/pep-0008/ With regards, Dipl. Phys. Jan M. Simons Institute of Crystallography RWTH Aachen University _______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Hi All,
Although Pavel's concerns are totally valid, especially from "senior
developer" point of view, I'd like to outline my opinion on this proposal.
Generally, I would prefer well-established, supported and maintained
external tool for whatever task we are trying to accomplish, if such a tool
exists.
Pros here are:
- No need to reinvent the wheel
- No need to maintain home-made tool
- No need to maintain documentation and teach newcomers how to use this
tool.
- We eventually may have 'extra' functionality for free when broader user
community of the tool starts to use it (Just to name a few: framework
support, analytic tools)
Cons:
- Usually we don't have a full control over the external tool
- If the analog is already implemented and tested and stable (see libtbx
testing world) it is really hard to convince ourselves why even think about
something else.
I acknowledge that libtbx testing may be implemented before python unit
tests. I'd like to point that clarity and atomicity of tests is depend
greatly on the developer who writing it, not on the testing framework.
I think that cctbx project would benefit if tested and working support of
python unittest functionality would be in place at least as a spare wheel
if something will go wrong with libtbx testing.
Therefore, in my opinion, Diamond people should try to implement this idea
in some small part (submodule, etc), test it, probably come up with some
guidelines tailored to use of unittest in cctbx. I'm sure that it should be
possible to demonstrate that libtbx tests are not as different as one may
think and the difference may reside only in class/function headers.
Best regards,
Oleg Sobolev.
On Tue, May 19, 2015 at 3:56 AM,
HI All,
I would like to echo these comments - there are times when cctbx can feel "different at any cost" which continually makes it harder to encourage people to adopt it as a basis for doing methods development. We should welcome opportunities to make things more pythonic when they do not break what we have at the moment. The testing is one such example.
I appreciate that many of the "differences" are for a real reason, but equally saying "we don't do python unit tests, we do it *our* way" could easily be interpreted as being ... unhelpful ... to the new user or developer. I for one want these people to contribute to the project and make it better!
Here at Diamond we have completely committed to using cctbx for a really rather large range of things, but even so persuading other people here to also use it is harder than it really needs to be. Installation complexity is just one reason...
Best wishes Graeme
-----Original Message----- From: [email protected] [mailto: [email protected]] On Behalf Of Jan Marten Simons Sent: 19 May 2015 11:22 To: cctbx mailing list Subject: Re: [cctbxbb] Native python unittests for the libtbx testing framework
Am Freitag 15 Mai 2015 18:07:33 schrieb Pavel Afonine:
Hi Markus,
lucky you, I wish I have time for side projects!
I've been working on cctbx (and writing tests!) for the past 12 years and can't name any problem using "libtbx testing world". Most tests are written this way. Why I am not so keen to use an alternative? - why introduce inconsistency for no obvious clear pressing reasons; - I have no spare time to learn and get used to an alternative framework (again, for no obvious clear pressing reason); - some rare developers (mostly postdocs that come and go) used Python test framework in the past on the code that I work too and that I have to maintain when people are gone. I find it is an irritating overhead for me dealing with these tests, so typically I bother to re-write them to use libtbx tools.
Hi Pavel,
those are sound and valid reasons from your point of view. But please also consider this alternative view: Coming from other python projects people are likely to have experience with the python unit test framework. As cctbx is using its own testing functionality people might be put off from writing tests or at least have to overcome this additional barrier on entry.
I'm a strong supporter of sticking/moving to standards like PEP0008 [1] or pip/whl* based installs as conforming to those helps people to quickly find their way into the code.
* wouldn't it be great if one could simply tell people this: "To install cctbx simply type 'pip install cctbx' in your terminal."?
[1] https://www.python.org/dev/peps/pep-0008/
With regards,
Dipl. Phys. Jan M. Simons
Institute of Crystallography RWTH Aachen University _______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
Hi Graeme, points you made are all good ones and I don't think anyone argues. Also, I don't think anyone stops you from doing things your way, cctbx is open source after all. If you want to use Python test frame work - feel free to go ahead and use it (and you don't have to ask me or anyone else for permission). Markus asked for opinions and I voiced mine. All the best, Pavel On 5/19/15 3:56 AM, [email protected] wrote:
HI All,
I would like to echo these comments - there are times when cctbx can feel "different at any cost" which continually makes it harder to encourage people to adopt it as a basis for doing methods development. We should welcome opportunities to make things more pythonic when they do not break what we have at the moment. The testing is one such example.
I appreciate that many of the "differences" are for a real reason, but equally saying "we don't do python unit tests, we do it *our* way" could easily be interpreted as being ... unhelpful ... to the new user or developer. I for one want these people to contribute to the project and make it better!
Here at Diamond we have completely committed to using cctbx for a really rather large range of things, but even so persuading other people here to also use it is harder than it really needs to be. Installation complexity is just one reason...
Best wishes Graeme
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jan Marten Simons Sent: 19 May 2015 11:22 To: cctbx mailing list Subject: Re: [cctbxbb] Native python unittests for the libtbx testing framework
Am Freitag 15 Mai 2015 18:07:33 schrieb Pavel Afonine:
Hi Markus,
lucky you, I wish I have time for side projects!
I've been working on cctbx (and writing tests!) for the past 12 years and can't name any problem using "libtbx testing world". Most tests are written this way. Why I am not so keen to use an alternative? - why introduce inconsistency for no obvious clear pressing reasons; - I have no spare time to learn and get used to an alternative framework (again, for no obvious clear pressing reason); - some rare developers (mostly postdocs that come and go) used Python test framework in the past on the code that I work too and that I have to maintain when people are gone. I find it is an irritating overhead for me dealing with these tests, so typically I bother to re-write them to use libtbx tools.
Hi Pavel,
those are sound and valid reasons from your point of view. But please also consider this alternative view: Coming from other python projects people are likely to have experience with the python unit test framework. As cctbx is using its own testing functionality people might be put off from writing tests or at least have to overcome this additional barrier on entry.
I'm a strong supporter of sticking/moving to standards like PEP0008 [1] or pip/whl* based installs as conforming to those helps people to quickly find their way into the code.
* wouldn't it be great if one could simply tell people this: "To install cctbx simply type 'pip install cctbx' in your terminal."?
[1] https://www.python.org/dev/peps/pep-0008/
With regards,
Dipl. Phys. Jan M. Simons
Institute of Crystallography RWTH Aachen University _______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
participants (4)
-
Graeme.Winter＠diamond.ac.uk -
Jan Marten Simons -
Oleg Sobolev -
Pavel Afonine