As well as not being necessary for the example, it also had the problem of
not actually having the input in focus (there was no press of 'tab' to kick
things off) and so the other keys didn't go into the `Input` as they were
supposed to.
Sometimes, when building the docs, this would end up being a bit of an
"empty" example in that the time taken to get the result back from the API
would be so long that the output would be of the request just in progress.
So we've decided to drop this from the front page.
This will build the docs into a directory called docs-local, sans the blog.
Note the near-total copy/paste of the `nav` due to how mydocs does
configuration inheritance; this is fine for now.
With #631 in mind, start by moving the vast bulk of the documentation
configuration into a "common" file, and just keep the `nav` in the main
configuration file. The thinking here is that I want two entry points -- one
for building the full docs for the Textual website, and one for building a
local version of the docs.
Because mkdocs doesn't allow for inheriting a configuration and also
splicing into the `nav`, we'll be looking to duplicate the `nav` for now --
this will likely change eventually as that'll be a maintenance overhead that
we don't really want (will likely look at templating it or something). For
now though, let's look at the best way of splitting things up and seeing how
we can generate two different versions of the docs.
As requested in #631 and also #1349; this change should cause the tests (and
also the examples from the docs directory which get pulled into the tests)
to be pulled into the sdist.
With this change I can:
- `poetry build`
- Grab and extract the resulting tarball
- `poetry install --extras dev` inside the resulting directory
- `poetry run pytest -vv tests` inside the resulting directory
As I understand the request, I think this should provide everything
necessary.
NOTE: We have spoken about rolling the CLI tools into snapshot tests too, so
if that happens we should remember to make sure that the pipeline outlined
above still works fine.
After some internal discussion we've decided to keep `Tree.clear` as it was,
and add a `Tree.reset`, which does a `Tree.clear` but resets the label and
data of `Tree.root` to the values given, while mirroring how `Tree.__init__`
takes those parameters.
Just before doing the commit I decided to rename the test tree in the new
unit test for clearing down a tree. Of course I managed to name it in such a
way that it becomes special to pytest.
This fixes that.
See #1437 for background. While it would be ideal to allow for the complete
emptying of a Tree, the root node is required (and it's part of the
construction of a Tree). So, here, when clearing the Tree we optionally
allow for a new label to be given.
Ideally we'll also allow for fresh data to be provided too; but there's a
wrinkle there in knowing the difference between the data being None, and no
data being provided (so the current root's data being carried over).
Following the method of defaulting used in __init__ would cause problems. As
such, rather than roll all of this into one commit, this goes with the basic
requirement and the solution for data will follow.
Note this also starts some unit tests for the clearing of a Tree.
