routing conflict with TiddlyWebWiki

[FND]

after installing/activating tiddlywebwiki, GET /tags results in the following error:

404 Not Found: tags not found, unable to get recipe tags: [Errno 2] No such file or directory: 'store/recipes/tags'

presumably that's a precedence conflict with friendlywiki

@cdent: Is there a better solution than requiring a certain order inconfig['system_plugins']?

FWIW, @pmario had a similar issue recently with logout.

[cdent]

Your analysis is correct, and no, there isn't really (at this time) a better solution than ordering in system_plugins. It's list on purpose after all.

That you're seeing this at all is an intended consequence of adding friendlywiki, but is a known principle in the entire selector stack and configuration.

In practice tiddlywebwiki has been first in most *_plugin stacks. The fact that it has a weird name is an indicator of its special status.

I'm not sure if there is a good fix, but there probably does need to be better documentation of these kinds of things. This is a good example of the sort of details in between that don't get covered in the docs (which is more sort of api docs).

[FND]

Roger, thanks. I'll leave this open as reminder to add some documentation to tiddlyweb.tiddlyspace.com.

[cdent]

I realized a few hours after I wrote my previous comment that I actually can't remember which order matters when adding to the selector stack. My comment implies that tiddlywebwiki should go first, but I think it is actually the case that because it goes first, it "wins". Clearly it is not clear and should be made more so.

[FND]

You might be right - from IRC:

<FND> I reckon it depends on the load order
<pmario> its:     'system_plugins': ['tiddlywebwiki','tiddlywebplugins.logout'],
<FND> so try reversing that

After that it worked.

I actually think that's a bit confusing; last wins seems more intuitive?

[cdent]

As with most things in tiddlyweb the api is layer is a very very thin thing over the whatever the data structure is. So, in Selector, the routes are a sequence. Each time config['selector'].add(...) is called from a plugin the new route is added to the end of the sequence. Since tiddlyweb calls init on each plugin in the order they show up in system_plugins the routes get added to the end of the Selector sequence. And Selector takes the first match.

The thinness is nice from a maintaining many options and keeping things inspectable sense, but I suppose not entirely friendly, but that's in keeping with the entire ouvre.

A util method that did an add_before_or_append is perhaps worth considering.

[pmario]

I think any order is possible, if there is some documentation, that for some plugins the order is important and how it works (cdent's comment above).

IMO one problem here seems to be that tiddlywebwiki is different to tiddlywebplugins.logout. If it would be tiddlywebplugins.tiddlywebwiki any order would be intuitive.

[pmario]

For https://pypi.python.org/pypi/tiddlywebplugins.urls/0.6.1 I did add a lot of text to the intro doc and disable the friendlywiki config.

# it needs to be disabled.
'tiddlywebwiki.friendlywiki': False,

But probably changing the order would have worked here too but I didn't think/know about it.