Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Alternative way to make anchor_link_text configurable #522
One of the features that I don't like about this is that it puts a filter inside the html exporter. This would mean for someone who wanted to grab the filter from nbconvert, they would need to know to go to the exporter to find the filter as opposed to the
I think we do have filters that are defined within exporters elsewhere, but I think it somewhat breaks nbconvert's architectural promises.
In addition to these user facing concerns it introduces some software dev issues. This PR overwrites a function inside this exporter that is only used (in first party code) by this exporter. That means that now we have to maintain two different pieces of code that now have different functionality, but the same name and are used to (ostensibly) accomplish the same things. To the extent that we think that
I understand why this is the kind approach that "needs" to be pursued in order to be able to apply the configuration here (given that filters are functions and therefore can't easily inherit configuration values from their parents). But that's exactly why making filters themselves configurable in the vein of #520 (i.e., without breaking any APIs) seems like (to me at least) the way to go.
I don't think there's anything wrong with an exporter redefining a generic filter to do something more specific (in this case, using a config option on the exporter).
Not really, to my mind. The new one is a trivial wrapper around the old one. Having configurable filters seems like more maintenance burden.