These are chat archives for cherrypy/cherrypy

11th
May 2016
Nicklas Börjesson
@nicklasb
May 11 2016 11:42
Do we have any areas of CherryPy that needs more testing? Looking at the coverage, something like session would be a candidate, however it would need mocking and is otherwise is mostly cleanup stuff on expiry and similar.
But:
  • are there any areas that those in-the-know feels will not be broken anytime soon and therefore are good candidates for work
  • do we have some kind of testing philosophy to avoid testing too much or too little
Nicklas Börjesson
@nicklasb
May 11 2016 11:50

For example, I talked to @jaraco privately about why requiring a test here: cherrypy/cherrypy#1432
Yes, there are cases were it is good to keep tabs on more subtle bugs that way.
However in that case, it felt like we were testing ntob and that it might do more to lock down the code and raise the bar for contribution than any actual good.
That ended up not turning out to be a problem, but as I have become more BDD:ish lately(however not purely, as I feel that they sort of both have their place), I have become a little bit more selective about testing.

Anyway, it would be good if we all knew where it’s at and why.

Nicklas Börjesson
@nicklasb
May 11 2016 12:11
(to be clear, I am not in any way proposing changing to BDD, just asking if there is a lower bound)
Nicolas Grilly
@ngrilly
May 11 2016 13:10
@jaraco What are the 5 features of Slack you prefer over Gitter? (I'm curious)
I'm having an issue with the filename's encoding of uploaded files. The filename is transmitted by the web browser in the Content-Disposition header. The problem is that most browsers encode the filename in UTF-8, but CherryPy incorrectly decodes it as ISO-8859-1 (https://github.com/cherrypy/cherrypy/blob/master/cherrypy/_cpreqbody.py#L623). Any advice on this?
Jason R. Coombs
@jaraco
May 11 2016 15:42
@nicklasb: Regarding cherrypy/cherrypy#1432, the test I was asking for was not to test ntob, but to test the expectation that unicode paths in redirects are handled as expected (and to document what ‘expected’ is). I’m still not completely certain that implementation is most correct, but having the test in place means if someone has a criticism, they can reference the test and point out how it’s wrong. The test prevents someone from simply mutating the code to some other preference.
Nicklas Börjesson
@nicklasb
May 11 2016 15:44
Aha, I see. If there is are uncertainties and preferences involved, then I agree.
Nicklas Börjesson
@nicklasb
May 11 2016 15:49
@jaraco Anyway, do you have any ideas were one should focus on adding tests? I thought I read somewhere a while ago that there was some parts of CherryPy that was a bit so-so, but it wasn’t completely obvious to me before when I ran the tests and looked at the coverage.
Jason R. Coombs
@jaraco
May 11 2016 15:53
@ngrilly: push notifications in the mobile app (I’m not getting any currently), IRC gateway (for re-using existing IRC bots), nicer startup behavior (Gitter App on mac insists on popping up on login; no way to hide it; gitterHQ/gitter#44), support for long-form content (Snippets), richer integration framework.
I could probably come up with more, but I’d start to get into nit-picking. And my instinct is still that Gitter largely comparable, and probably a better fit for open-source applications such as cherrypy.
Nicklas Börjesson
@nicklasb
May 11 2016 15:54
I could, something like that the gitter app user return to send. And that messages on the app cannot be edited. That is crappy. Not nit-picking.
Jason R. Coombs
@jaraco
May 11 2016 15:55
I edited my message above in the app.
Nicklas Börjesson
@nicklasb
May 11 2016 15:56
What??
Jason R. Coombs
@jaraco
May 11 2016 15:56
Oh, you mean mobile app?
Nicklas Börjesson
@nicklasb
May 11 2016 15:56
Yes.
Nicolas Grilly
@ngrilly
May 11 2016 15:56
@jaraco Those are valid requirements. I don't use the desktop and mobile apps. :-)
Gitter is definitely younger and less founded than Slack.
Thanks for sharing!
Nicklas Börjesson
@nicklasb
May 11 2016 15:58
Well, it is not that young. And slack isn’t so young that it excused of having a really wierd team structure with, for some extraordinary silly reason, separate logins.
Jason R. Coombs
@jaraco
May 11 2016 15:58
@nicklasb: I can’t really say about tests. I’m not that familiar with the whole of the test suite. I’ve only worked on isolated components. My sense is that the test suite is largely adequate to support substantial refactoring, but does have some gaps.
Nicolas Grilly
@ngrilly
May 11 2016 15:58
Yes, separate logins is a really big issue with slack.
Nicklas Börjesson
@nicklasb
May 11 2016 16:03
@ngrilly And as far as I know from everything I have ever worked with, completely unnecessary.
@jaraco Ok. I feel that is sort of telling, we don’t seem to have an overarching sense of the system in the community. I feels like the system design and its state isn’t described very well anywhere, it isn’t clear who knows what and what is to know.

The module have pretty good module level descriptions in the code, but where they are in the system in general is, while obviously possible to understand, not easy to understand.

(I get push notification on my OSX app, you haven’t denied some gitter e-mail somewhere, I remember vaguely that I had some problems with that)

Jason R. Coombs
@jaraco
May 11 2016 16:06
I’d say that condition is pretty common for any community-maintained application. The knowledge is distributed. I expect Lawouach probably has the best breadth of knowledge of the product.
Nicklas Börjesson
@nicklasb
May 11 2016 16:08
It is certainly common, that is why it is important to try and document that knowlegde.
Nicklas Börjesson
@nicklasb
May 11 2016 16:25
Eh. It is not important because it is common, but because it is important. :-)
If anyone wants to add to this article, it would help. I have added all I know. :-)
https://github.com/cherrypy/cherrypy/wiki/System-design
Nicklas Börjesson
@nicklasb
May 11 2016 16:38
And by that I don’t mean “it is a function…” and a link to the zen of CherryPy… :-)