I was at first more inclined towards solution A in order to keep devpi small and clean (as perhaps some people have no use for these fancier web interface/search capabilities) but thinking more and more about it, I think solution B is the one that makes most sense.
The server itself will stay small (even smaller than today). The web interface is a separate package which when installed will augment the server. The details are still a bit in flux while we are experimenting, but that is the grand goal.
For instance, if the documentation has to be indexed, not only would the web component needs to have access to internal data structures but perhaps documentation source as well.
That is indeed the case.
I am not sure how much thoughts have been put into this already but I think it would be important to enable the user to specify the search context, which could be "index only", "index tree" or "server".
This could be useful when we want to ignore upstream/downstream versions of projects.
You mean limited to the user in this case, or do you mean the inheritance of the index (afaik there are plans to enhance the inheritance possibilities)?
I can see a case where someone wants to find out where project "X" lives which is kind of difficult today if you have a large number of users and indices.
This will certainly be the case. My first experiments were already so useful and fast, that I started to search for pypi packages with the local interface :)
There is also the question of version specifier. For project A, we may have 10 versions of the documentation (one for each release file). So I think it would be useful to be able to scope in that dimension as well (like == 1.0.2, <= 3.1, etc).
This is certainly something we still have to think about and test. The operators on the version are a nice idea and should be easily added.
The biggest question is the UI. The query language is pretty powerful, but not necessarily easy to use. There will be a help page for it. At least for the more common use cases we should have a web UI for the filtering. Once there basics are useable through the query language I would really like some ideas on that.
It this something intended to be supported?
I have to read up on that. Holger and I discussed this briefly but have no definite plans yet.
Regards, Florian Schulze