static support should be moved to cheroot?

[absurd34]

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [x] question about the decisions made in the repository

Hi!

I am using cherrypy's internal HTTP implementation only.

With cherrypy up to version 8.9, I could just modules
cherrypy.lib.* to provide delivery of static files.

With the cheroot split, these tools remain with cherrypy, so, in simple terms, "staticdir"
is not possible with cheroot alone.

Am I missing s.th. here?

Thanks!

[webknjaz]

Makes sense to me, but I won't have time to explore this soon.

/cc: @jaraco what do you think?

[jaraco]

The split of cheroot was intended to move the HTTP server (specifically everything that was in cherrypy.wsgiserver) to another library. I don't see how it follows that the static file support, which is a feature of cherrypy like anything else in cherrypy.lib. Looking at the implementation, the behavior depends on cherrypy.serving.response and cherrypy.log and cherrypy.NotFound. None of these concepts make any sense outside cherrypy.

I took a quick look at waitress and zope.server, two projects in the same space as cheroot, and neither of those have static file support.

So I'm finding it difficult to imagine what it looks like to have static file support in cheroot, what impact that would have on cherrypy, and who would use such a thing. Why not use CherryPy? How is it you were using CherryPy before to serve static files with just the cherrypy.lib modules?

[webknjaz]

Okay, now I see. It sounds reasonable for me to wontfix it since I didn't have a chance to look through implementation detail. Also since it's tightly coupled with CherryPy and its feature set I guess it would be hard to find and move bits of implementation here.

@absurd34 if you 100% want to serve just statics with Python, why don't you use stdlib http.server? (yeah I know that it's slower)

Cheroot intends to provide just HTTP+WSGI layer for apps (like just parsing HTTP and sending response over the wire). Serving files is higher level abstraction, which is not related to current project.

[absurd34]

Thanks for the comments, that to some extend clears it up for me.

However, @webknjaz , my actual use case at hand is to provide both, static and wsgi support (django app), all from python code, and in production quality. cherrypy+wsgiserver has served me really well for that in the past.

The cheroot split sounded like exactly for my use case, so I was wondering what purpose the split actually served when it wasn't ;) I hope I got it right now from your comments that those who choose to use cheroot w/o cherrypy have other means to provide static support anyway, and that also is the common use case (and mine is odd ;).

Thx!

S

[webknjaz]

I'd say you understand that correctly. Closing the issue if you do not mind.