Persistence fix #944
Persistence fix #944
Conversation
also don't bother with sdist for dash, it has no artifacts
| find . -name "*.gz" | xargs pip install --no-cache-dir --ignore-installed && pip list | grep dash && cd .. | ||
| find . -name "*.gz" | xargs pip install --no-cache-dir --ignore-installed && cd .. | ||
| sed -i '/dash/d' requires-install.txt | ||
| pip install --no-cache-dir --ignore-installed . |
There was a problem hiding this comment.
FYI @byronz - the issue I was having in this PR is related to the original one that led to the sed call during build-core: sometimes (seemingly at random) the dash-renderer we prepared in packages was being overwritten by a published one from PyPI - so I used essentially the same solution, but extended to dash-renderer by using the pattern /dash/d rather than /dash-/d.
Also I skipped creating a tarball for dash itself because (a) we already have everything we need here, dash has no build artifacts, and (b) that made it easier to modify its requirements.
| dash_duo.wait_for_text_to_equal('#out', 'a') | ||
|
|
||
| dash_duo.find_element('#persistence-val').send_keys('s') | ||
| time.sleep(0.2) |
There was a problem hiding this comment.
I see you've removed all the other sleep. Is this one special / still required?
There was a problem hiding this comment.
yes - I'm expecting the same text both before and after the send_keys, so there's really nothing to wait for; I inserted an explicit wait just to ensure the keypress had fully registered.
Edge case discovered while writing persistence docs: failure when enabling/disabling persistence on an existing component.
As discussed with @byronz I also generalized some of our test methods to accept either an element or a CSS selector.
CHANGELOG.md