Feature request: support different end points

[beliaev-maksim]

It looks like that local server can serve only one request. What will be the recommended path to serve different content depending on different URL path?
example.com/one -> serve [200, "OK"]
example.com/two -> serve [201, {"json": "data"}]

would be cool if this functionality could be expanded.

for the moment it looks to be possible to achieve it with https://github.com/csernazs/pytest-httpserver

[RonnyPfannschmidt]

the wsgi server functionality allows to do those elements as of now (via a wsgi app)

as far as im aware nothing else has been integrated

[diazona]

I wouldn't be opposed to adding this feature, but now that I look at that other project, I kind of wonder what the point is of maintaining pytest-localserver. When there's a better project that provides the same functionality, it makes sense to suggest that people use it.

[beliaev-maksim]

I kind of wonder what the point is of maintaining pytest-localserver.

@diazona, @RonnyPfannschmidt
that would make even more sense to avoid redundant work.

maybe we can discuss with @csernazs about his future plans and eventually move the repo to @pytest-dev to ensure project long-term support

[diazona]

FYI @redtoad @coordt @nicoddemus as the other maintainers of this project

[redtoad]

I kind of wonder what the point is of maintaining pytest-localserver.

Naturally, I'm very much opposed to this. 😉 pytest-localserver was always supposed to provide a local server for tests. HTTP is just one supported protocol.

[beliaev-maksim]

@redtoad
isn't it just a name of the package? :)
it looks like pytest-httpserver can do everything that pytest-localserver can and even more

[diazona]

As things stand now, the only protocols supported by this package are HTTP(S) and SMTP. The SMTP support is on thin ice, so to speak, because we do not have a well maintained SMTP server backend; there's a good chance it might have to be dropped at some point in the future. That leaves the HTTP(S) support, and it looks like pytest-httpserver does that better, with the possible exception of a couple minor features which I'm sure could be added to it.

That leaves me pondering the question, what reason is there for people to use pytest-localserver over pytest-httpserver? Imagining myself as a third party developer, the only advantage I would get out of using pytest-localserver is the fact that it's part of the pytest-dev organization, which brings some sort of "guarantee" of stability. That certainly has some value, and I don't mind continuing to help maintain the package just so that there is something within the organization providing that functionality, but my motivation is a lot lower if that's the only reason I'm doing it.

[redtoad]

Hi @diazona I find myself disagreeing with you. I see no problem in another package providing a more specialised or wider feature set, and in this reagard pytest-httpserver does bring a lot to the table. Personally, and I'm certainly biased, prefer a simpler API.

However, to get back to the original discussion, do we want to support multiple endpoints when this can be achieved by the exsting means already (i.e. a WSGI app as @RonnyPfannschmidt has pointed out)? How could this look?

[diazona]

However, to get back to the original discussion, do we want to support multiple endpoints when this can be achieved by the exsting means already (i.e. a WSGI app as @RonnyPfannschmidt has pointed out)? How could this look?

I think that kind of does tie in to the other question, in the sense that we should think about what the purpose of this package is and why people would use it over pytest-httpserver (or other alternatives). For example, if one of this package's goals is to provide a simpler API, maybe it makes sense not to add any special support for multiple endpoints. 🤷

Personally, I place less value on having a simple API - or at least, I think the API of pytest-localserver is nowhere near complex enough that adding extra features is a problem. So I would be fine with adding some support for multiple endpoints. I'm not sure what the best way to do it is, but here are some ideas:

• Add an optional parameter to the serve_content() method to specify the endpoint
• Create a new RequestFilter class, or something like that, which acts like httpserver except that it only responds to requests matching some criteria, and have people call that object's serve_content() method (this is superficially similar to what pytest-httpserver does)

[RonnyPfannschmidt]

A custom wsgi server is practically just a webapp written with something like flask or plain wsgi, it's pretty low level and painful

[The-Compiler]

FWIW, I might be the minority needing more complex features here, but personally I'd love the ability to just plug in a custom Flask (or probably other WSGI) app. Currently, what I do for qutebrowser is the following:

• Have a testprocess.py, which can manage external processes for tests (perhaps somewhat similar to pytest-xprocess?)
• Have a webserver.py, which manages an external webserver process and interprets its output (which is expected to be JSON)
• That then spins up a cheroot (pure-Python) WSGI server which is configured to log requests via JSON
• And runs a custom Flask app which provides endpoints for things like delayed request answers, redirects, etc. etc. (heavily inspired by HTTPbin, it actually used to be based on it)

This solution has worked quite well for me ever since I started building it back in 2015 - but at the same time, cheroot has some odd bugs here and there, so perhaps a solution where I could just plug my Flask app into a pytest plugin would be easier.

Perhaps this is too far away for what this plugin is looking to provide - if that's the case, I understand. Maybe some day I will get around to building my own thing (a pytest-wsgiserver or so?).

[RonnyPfannschmidt]

hmm, i just took a look at the codebase, and it may be a good idea to phase this library out as its really only setting singular predefined responses, and isn't integrating any server yet

right now its not even trying, and the others seem to be way ahead

[The-Compiler]

If that's done, at least the SMTP part should probably be in a new pytest-smtpserver project or so. I'm not really aware of any good alternatives for that, and as evident by #30 or https://twitter.com/MelineSieber/status/1547907713740378119 it's in active usage (even if aiosmtp is unmaintained...).

[diazona]

Let's move the discussion about whether to retire the package to #46, and that way we can keep this issue focused on adding support for different endpoints.