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.

[diazona]

@beliaev-maksim I've been reviewing this discussion... I wanted to check, for your use case, is (or was) there any particular reason you really needed this feature added to pytest-localserver specifically? Or is using pytest-httpserver instead a valid option for you?

[beliaev-maksim]

@diazona well, serving different paths with different responses is essential for testing :)

however, for the benefit of the community it would be extremely valuable if we can somehow agree with pytest-httpserver and take it under umbrella of pytest. pytest-httpserver looks to be more feature reach but lacks this wider community guarantee (if you see what I mean). While pytest-localserver has opposite

do you see any path forward how we can take the best from both worlds ?

[diazona]

Well, whether it's essential for testing depends on what you're doing with it :) In all the cases where I used this package, I never needed to serve different paths with different responses. And in particular, whatever use pytest itself makes of this package evidently doesn't require that feature either, or at least I assume so since nobody else has asked for it.

Anyway, I think there are two paths forward: either we retire this package, or we decide that it should be a proper competitor to things like pytest-httpserver and start developing it more actively. Or, I guess there's a third path forward where we keep the package in maintenance mode (making sure it continues to work but not really putting much work into new features, same as we've been doing thus far), but that is pretty similar to the first option. If we decide to actively develop this package, then I'd be happy to implement the feature you requested here, but if we decide to retire it or keep it in maintenance mode, I think it makes sense not to add new features. That's why I asked whether you still needed it.

The broader question of which path to take is probably a better topic for #46. (I do intend to reactivate the discussion there and figure out how much everyone else cares about this package sticking around; I just didn't feel like getting into it right now.)

[beliaev-maksim]

@diazona
I usually prefer to not compete and join forces on the common goal. But that is personal preference :)

we (as responses project) had to switch to pytest-httpserver for the purpose of testing different URL paths.

Generally, all the requests stuff could be easily mocked by responses and no need for a real HTTP server. However, for responses itself we need another tool which we use to validate we do good :D

[diazona]

Gotcha. Well, since you switched, for our purposes here I think that counts as not needing the feature anymore. Of course other people will still find it valuable if they have a reason to continue using pytest-localserver rather than switching.

(FWIW I'm the same way, I prefer to join forces rather than competing, except in some cases where it makes sense to have multiple implementations but I don't think this is one)