kinode-dao / kinode-book

"Rust Book"-style introduction and documentation for Kinode OS
Apache License 2.0
12 stars 8 forks source link

Section 4. and 4.X. Kit #186

Closed jurij-jukic closed 6 months ago

jurij-jukic commented 6 months ago

Section 4.1. Installation; Logging

  1. 'Logs are printed to the screen and stored, by default, at /tmp/kinode-kit-cache/logs/log.log.'
    • what does it mean that logs are printed to the screen?
  2. 'The default logging level is info.'
    • are the other logging levels explained somewhere?
  3. 'These defaults can be changed by setting environment variables'
    • might be good to have an example of an .env file
jurij-jukic commented 6 months ago

Section 4.2. kit boot-fake-node

  1. 'Version of Kinode binary to use (overridden by --runtime-path) [default: latest] [possible values: latest, v0.5.3-alpha, v0.5.2-alpha, v0.5.1-alpha]'
    • what are the latest versions which should be put here?
  2. 'Fetch and run a specific version of the binary; defaults to most recent version (here, 0.5.0).'
    • what's the latest version which should be put here
  3. '--network-router-port Run the fake node network router on this port; defaults to 9001. Additional fake nodes must point to the same port to connect to the fake node network.'
    • this is for testing indirect nodes?
  4. '--testnet Connect to the Sepolia testnet rather than the Optimism mainnet.'
    • connects to Optimism on Sepolia correct?
  5. '--persist'
    • how do you boot a persisted node again after it was shut down? I assume with --home. example would be useful here
  6. '--password The password of the fake node; defaults to secret.'
    • is secret some type, or an actual password value?
  7. '--verbosity Set the verbosity of the node; higher is more verbose; default is 0.'
    • what are the acceptable values for verbosity? where is it specified?

Some curiosity about fake nodes (mostly informed by how they worked on urbit):

  1. 'Though this lack of connectivity makes them easy to spin up and throw away, the downside is no access to services on the network, like remote LLMs.'
    • i remember fakeships on urbit being able to connect to the internet, just not interface with the live urbit PKI. isnt sth like this desirable for fake nodes as well? so e.g. you could test your LLMs from a fake node
jurij-jukic commented 6 months ago

Section 4.3. kit new

  1. 'You can create a variety of templates using kit new. Currently, three languages are supported: rust (the default), python, and javascript.'
    • is it explained somewhere how apps in different language (in general) work? Would love to link to it. This discussion about wit seems relevant https://github.com/kinode-dao/kinode-book/pull/182, but I dont think that section is the best place to explain apps in different langs
jurij-jukic commented 6 months ago

Section 4.4. kit build

  1. having a separate kit build-start-package page might make sense because that command still has a bunch of parameters (even if they are covered separately in kit build and kit start-package) and people might want to refer to it
  2. so far i've changed all aliases in examples to full cmds (i.e. kit b --help -> kit build --help), thought it would make it clearer, but now i'm not sure. it's probably useful to give an example of how to use aliases
nick1udwig commented 6 months ago

Section 4.1. Installation; Logging

  1. 'Logs are printed to the screen and stored, by default, at /tmp/kinode-kit-cache/logs/log.log.'
  • what does it mean that logs are printed to the screen?
  1. 'The default logging level is info.'
  • are the other logging levels explained somewhere?
  1. 'These defaults can be changed by setting environment variables'
  • might be good to have an example of an .env file
  1. Like printed to the terminal screen.
  2. No; maybe we should. Standard logging levels: debug, info, warning, error.
  3. Hmm, its not obvious to me there's much to gain from doing so, but I also have never used a .env; I just set in terminal with export. What do you see as the benefit of adding a .env?
nick1udwig commented 6 months ago

Section 4.2. kit boot-fake-node

  1. 'Version of Kinode binary to use (overridden by --runtime-path) [default: latest] [possible values: latest, v0.5.3-alpha, v0.5.2-alpha, v0.5.1-alpha]'
  • what are the latest versions which should be put here?
  1. 'Fetch and run a specific version of the binary; defaults to most recent version (here, 0.5.0).'
  • what's the latest version which should be put here
  1. '--network-router-port Run the fake node network router on this port; defaults to 9001. Additional fake nodes must point to the same port to connect to the fake node network.'
  • this is for testing indirect nodes?
  1. '--testnet Connect to the Sepolia testnet rather than the Optimism mainnet.'
  • connects to Optimism on Sepolia correct?
  1. '--persist'
  • how do you boot a persisted node again after it was shut down? I assume with --home. example would be useful here
  1. '--password The password of the fake node; defaults to secret.'
  • is secret some type, or an actual password value?
  1. '--verbosity Set the verbosity of the node; higher is more verbose; default is 0.'
  • what are the acceptable values for verbosity? where is it specified?

Some curiosity about fake nodes (mostly informed by how they worked on urbit): 8. 'Though this lack of connectivity makes them easy to spin up and throw away, the downside is no access to services on the network, like remote LLMs.'

  • i remember fakeships on urbit being able to connect to the internet, just not interface with the live urbit PKI. isnt sth like this desirable for fake nodes as well? so e.g. you could test your LLMs from a fake node
  1. Easiest way to update these is just just run that same command and copy-paste output from terminal.
  2. Let's get rid of the (here, blah) part.
  3. Leave this alone, this needs to be updated; paging @bitful-pannul : could you please update the docs here and elsewhere in kit docs to reflect changes made when adding anvil?
  4. Yes, this is old and should be removed.
  5. Yes. Good idea. See if you can do it; if not I can help.
  6. Actual password value. Maybe we should quote it.
  7. https://github.com/kinode-dao/kinode?tab=readme-ov-file#terminal-syntax
  8. So the lack of connectivity is to the Kinode network, not the internet. Fake node can talk to internet just fine. @bitful-pannul just pushed a PR to make it so they run on a local fake ETH chain powered by Foundry's anvil. So we are talking specifically about services provided over the Kinode network. The plan is to make LLMs quite accessible, and so that's why the LLM reference is there. Feel free to reword; I agree that it is confusing.
nick1udwig commented 6 months ago

Section 4.3. kit new

  1. 'You can create a variety of templates using kit new. Currently, three languages are supported: rust (the default), python, and javascript.'
  • is it explained somewhere how apps in different language (in general) work? Would love to link to it. This discussion about wit seems relevant Section 3. Process Standard Library #182, but I dont think that section is the best place to explain apps in different langs

Agreed section 3 is not the right place for the discussion -- that lib is specific to Rust.

Looks like we do not have such a document: https://book.kinode.org/?search=language

I agree we should add one, but I don't think we should do so right now. Although we technically support py & JS, it is a somewhat trivial level of support: to make it full-featured we really need to build out process libs in those langs. Could you open an issue?

nick1udwig commented 6 months ago

Section 4.4. kit build

  1. having a separate kit build-start-package page might make sense because that command still has a bunch of parameters (even if they are covered separately in kit build and kit start-package) and people might want to refer to it
  2. so far i've changed all aliases in examples to full cmds (i.e. kit b --help -> kit build --help), thought it would make it clearer, but now i'm not sure. it's probably useful to give an example of how to use aliases
  1. Sounds good, plz do add
  2. Yeah, my intent was that these would illustrate the aliases through use ("I'm on build page and its showing kit b, oh I guess thats an alias"). If you think its unclear we can change it to the full ones
jurij-jukic commented 6 months ago

Section 4.9. kit run-tests

  1. 'Consider the following example, from [core tests]():'
    • i cannot find the link for core tests.
    • would prefer to link to that tests.toml file because it makes it incredibly clunky to read the page. I broke down each section with its corresponding example code
  2. I removed the directory tree because i dont think it helps understanding and also makes the page really clunky to read
  3. https://book.kinode.org/kit/run-tests.html#test-package-format
    • is there a link where this interface is formally specified?
nick1udwig commented 6 months ago

Section 4.9. kit run-tests

  1. 'Consider the following example, from core tests:'
  • i cannot find the link for core tests.
  • would prefer to link to that tests.toml file because it makes it incredibly clunky to read the page. I broke down each section with its corresponding example code
  1. I removed the directory tree because i dont think it helps understanding and also makes the page really clunky to read
  2. https://book.kinode.org/kit/run-tests.html#test-package-format
  • is there a link where this interface is formally specified?
  1. https://github.com/kinode-dao/core_tests
  2. Ok, will review
  3. https://github.com/kinode-dao/kinode/blob/main/kinode/packages/tester/tester_types.rs#L18-L57

Interface will change with wit work I'm doing now, but that's where it lives for now.

jurij-jukic commented 6 months ago

Re 4.1. kit installation

  • No; maybe we should. Standard logging levels: debug, info, warning, error.

Mentioned these. Even if they are not explained, I still think it's good to have them.

Hmm, its not obvious to me there's much to gain from doing so, but I also have never used a .env; I just set in terminal with export. What do you see as the benefit of adding a .env?

That works too, just wanted an example of how to use. Added an export example.

jurij-jukic commented 6 months ago

Re 4.2. kit boot-fake-node applied all I could from there. please check the --persist part, and the 'lack of connectivity to live network' part at the end of 'Discussion'

re Q7, terminal syntax. I will link that in the terminal section, and here just say what are the acceptable verbosity values

jurij-jukic commented 6 months ago

Re section 4.9. on tests tests.toml snippets in the doc are outdated. (and prob some other stuff) should I wait for @bitful-pannul's work to finish before updating the doc, or no more changes will be made?

jurij-jukic commented 6 months ago

Section 4.4. kit build Added --no-ui option in kit build, it wasn't documented before

nick1udwig commented 6 months ago

Re section 4.9. on tests tests.toml snippets in the doc are outdated. (and prob some other stuff) should I wait for @bitful-pannul's work to finish before updating the doc, or no more changes will be made?

I think he will do a pass after this is merged.

jurij-jukic commented 6 months ago

@nick1udwig

then we can finally merge this!