Open FND opened 10 years ago
We've been over this several times in the past and decided that the various bootstrapping issues made it easier and less noisy (from a user's standpoint) to have instance scripts and not use twanager.
I'm aware, which is why this isn't on the beta milestone - I wanted to a) make it explicit (and record the mechanism) b) revisit it in the future for a final verdict.
what makes the OP unappealing is the lengthy command - however, with a bit of conventional magic that might be simplified to twanager --load bfw my-bfw
, which seems a lot more acceptable
there's sort of a precedent for such magic in the way stores, serializers, challengers, extractors and renderers are imported from the respective tiddlyweb.<...>
namespace - plus tiddlyweb.util:initialize_logging
establishes a "tiddlywebplugins" logger, so the core is already aware of this namespace
I still think a happily named instance script is much nicer; more accessible, more intuitive, more documentable. On top of that you're going against six years of beautiful history^wconvention.
The reason I don't like separate instance scripts is that they're so very rarely used (usually just once) - so it seems like a weird optimization.
Perhaps I should look into providing an entry point via python -m tiddlywebplugins.bfw
.
twanager bfw
seems nicer thanbfwinstance
, plus it doesn't pollute the executables namespacehowever, it's not quite that simple due to bootstrapping issues: twanager has an undocumented
--load
parameter which would allow us to usetwanager --load tiddlywebplugins.bfw.config bfw
* - that should suffice, but is obviously a lot less nice* assuming that module has the appropriate
twanager_plugins
entry, which is not currently the case (cf. 4e92373b1d1d8f96926dd3022eb68569939d0c0b)