While it's still fresh in my mind as to why I wrote it like this, comment to
the effect so I'm not surprised by it in the future, or so someone else
reading it can know what the thinking was here.
It's a `Makefile` so it's handy to not have to think about if you need to be
within a poetry venv when running `make`. This commit adds a `poetry run`
before any command that needs the venv. This means that people who aren't in
a venv can just `make something` and it'll "just work", and the same is true
for those who are in a venv.
This has the effect of bundling up a bunch of files that would otherwise be
pulled in from the net on the client side. As well as enhancing the viewer's
privacy, it also means that we increase someone's ability to view
documentation locally without the need for any sort of working net
connection.
This removes the duplication of the screen cache cleaning, and also turns it
into a target so you can do it yourself from the command line if needed. It
also marks all the phony targets as such (that is, targets that aren't
actually items in the filesystem).
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.
See #1471. It seems useful and important for a Tree to still have a cursor
visible even when it doesn't have focus -- that ways someone can build a UI
where the user can tab away from the tree to something that relates to the
node, and still see which node is in play.
