On 4/30/14, 10:42 AM, Florian Schulze wrote:
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 meant within the current implementation limits bu not limited to the user (say if lpbrac/dev derives from florian/prod the search would apply to our index as well). I am kind of throwing things up in the air to see what sticks, hoping that others have opinions about this so we come up with a meaningful set.
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 :) Interesting ... I was about to say not to go there as it would be too much, but if it comes for free, then great :)
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. I think this would be useful indeed.
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. I think people should be able to figure out the query language and use it. What about saving filters so that they can be re-used by others as opposed to have built-in ones?
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.
This might get pretty complicated. Read The Docs seems to always point to the latest catalog of a project ... which is okay if this project is only in one place... I will try to educate myself on this as well to have something more meaningful to say. Again, just wanted to raise this up. It seems that this is already on the table.
Thanks for getting back to me.
Regards, Florian Schulze