but as soon as I set this flag to True (it makes my development a lot easier), Dash will silently exclude my file from the html served up in the index route of the application.
I’ve traced this behaviour to the Resources._filter_resources() function in dash/resources.py, where external urls are only served if serve_locally is False. Is there any reason for this restriction (equivalently: would you welcome a PR that enhances this logic)?
That PR looks really good, but I fear that I have a different use case - admittedly one that is probably an edge case.
I want to set serve_locally=True (to serve up the files I’m developing, as well as in general when I don’t have internet access) but also to have other extra files served from somewhere else - essentially some other server.
Right now, I’m using external_url in calls to append_css and append_script to achieve this, along with a patch of Resources._filter_resources. From a reading of the code - unfortunately I’ve not been able to try to run it - and the associated github notes, it looks like PR 286 won’t change this. Also, it isn’t really possible for me to cleanly put a copy of the extra files into an assets_folder directory that can be scanned by the code in PR 286, although some sort of kludge might work.
Of course, I may have misread things - but if not, I’m still in the same situation.
So with the new PR, you’ll be able to set your own index.html string and then include whatever scripts you want there. We’re also considering adding a scripts=[…] argument in the dash constructor (there are some comments in the PR with more info). Eventually, these methods will replace the existing append_script interface
Is something like this still possible somehow?
I’d like to locally serve some .css files.
However I do not wish to apply them directly by putting them into /assets/. I’d need them to be available for the server at e.g. /external_css/theme1.css, /external_css/theme2.css, …