Metadata-Version: 2.4
Name: ryry-cli
Version: 7.39
Summary: ryry tools
Home-page: https://github.com/dalipenMedia
Author: dalipen
Author-email: dalipen01@gmail.com
Classifier: Programming Language :: Python :: 3
Classifier: Operating System :: Microsoft :: Windows
Classifier: Operating System :: MacOS
Classifier: Operating System :: POSIX :: Linux
Requires-Python: >=3.9
Description-Content-Type: text/markdown
License-File: LICENSE
License-File: ryry/proxy/bin/LICENSE.MIHOMO
Requires-Dist: requests
Requires-Dist: websocket-client>=1.7.0
Requires-Dist: pillow
Requires-Dist: psutil
Requires-Dist: nvidia-ml-py>=12.0.0
Requires-Dist: requests_toolbelt
Requires-Dist: fake_useragent
Requires-Dist: gputil
Requires-Dist: urlparser
Requires-Dist: urllib3
Requires-Dist: portalocker
Requires-Dist: boto3
Requires-Dist: PyYAML
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: description-content-type
Dynamic: home-page
Dynamic: license-file
Dynamic: requires-dist
Dynamic: requires-python
Dynamic: summary

ryry Python Tool
===============================================
The ryry Python Tool is a official tool, you can use it to **Register** device to ryry server, other person can use **ryry Application** assign tasks to you for implementation

Installation
------------

The ryry requires [Python](http://www.python.org/download) 3.10.6 or later.

##### Installing
    pip install ryry-cli

##### Uninstalling
    pip uninstall ryry-cli

Use
------------
##### 1. Running
    $ ryry service start
start a process to wait for the server to issue tasks. **Please do not close it**

Module Developer
------------
    $ ryry widget init

in empty folder, use above command craete a ryry module, structure is like 
    
    [widget folder]
        |-- config.json     //*required, do not change*
        |-- main.py         //*required, do not change* 
        |-- run.py

if other person share widget code to you , you can add widget path in your computer to ryry environment

    $ ryry widget add [path_with_widget_code]

you can modify script and h5 file yourself, then publish to ryry sever 
    
    $ ryry widget publish

get ryry status
    $ ryry services status

Installation temporary files
----------------------------

Widget dependency installation and CLI self-upgrades run pip with a 30-minute
execution timeout. Each run selects a usable temporary location from `TMPDIR`,
`TEMP`, and `TMP`, in that order, falling back to Python's default temporary
directory. It creates an owned `ryry-pip-<uid>/run-*` workspace there on Unix
(`ryry-pip/run-*` on Windows), then sets all three variables to that workspace
for pip and its children only. No writable home directory is required. The
runner removes the workspace after success, failure, or timeout. On timeout it
terminates pip and its build child processes before removing temporary files.

On macOS/Linux, the next pip run also removes abandoned owned workspaces older
than 24 hours. A file lock inherited by pip protects workspaces still in use.
Windows performs per-run cleanup but does not perform the abandoned-workspace
sweep. These rules do not delete historical `pip-*` directories elsewhere or
pip's shared download/wheel cache.

Automatic widget updates and deployments persist a 30-minute cooldown after
failure under `ryry/_runtime/widget-updates/`. A different target version can be
attempted immediately; manual installation is not subject to this cooldown.
Wheel updates verify the installed version and, when available, the active
widget configuration before reporting success.

Run the offline regression tests with:

    python -m unittest discover -s tests -v

TLS certificates
----------------

WSS verifies both the certificate chain and hostname. By default it retains
system trust and adds the CA bundle used by Requests, so fresh python.org macOS
installs with an empty default CA store can connect securely. Explicit
`WEBSOCKET_CLIENT_CA_BUNDLE`, `SSL_CERT_FILE`, and `SSL_CERT_DIR` settings keep
their existing behavior. Otherwise, `REQUESTS_CA_BUNDLE` or `CURL_CA_BUNDLE`
can select a custom CA store. Invalid certificates are never accepted as a
fallback. HTTP, uploads, proxy nodes, and managed pip keep TLS verification.

On a Python 3.11 installation from python.org, that Python installation's
certificate setup can also be completed by running:

    /bin/bash "/Applications/Python 3.11/Install Certificates.command"

Restart the service after certificate setup or after installing the updated CLI.

Device identity
---------------

All devices use the new application-specific UUID derived from macOS
IOPlatformUUID (with a structured Hardware UUID fallback), Windows SMBIOS UUID,
or Linux machine-id. Hostname, MAC address, IP address and proxy selection do
not participate. Each process probes once and caches the result in memory;
independent processes derive the same UUID from the same platform identity.
No dedicated identity file is created or read. Old IDs in data.json and any
previous device_identity.json do not override the derived ID. Hardware/OS
identity changes (including resetting Linux machine-id) can still change it.

This release intentionally registers existing devices under new IDs. Restart
the service and its daemons together after upgrading; old server records are
left for the server's normal cleanup. Device-bound server configuration is not
migrated to the new registration. Current reports and the CLI display all use
the new ID even when existing metadata still contains the old one.

If platform identity cannot be read, resolution raises an error and may be
retried; it never substitutes a random ID that could split service and daemon
reports across different devices. Linux uses /etc/machine-id or its D-Bus copy,
not a transient network adapter or an unrelated hardware fallback.

An ID is not an authentication credential: live hardware queries cannot prevent
a local administrator from impersonating a client. Existing API authentication
remains responsible for access control.

Managed Mac mini permissions
----------------------------

On macOS hosts whose hostname starts with `zj-macmini-` (case-insensitive),
service startup and successful widget installations/updates automatically
repair the managed `ryry/widget` tree and the installed
`template_generator/bin` resource tree. Run the service with sudo from the
normal task account; the repair uses the same selected task user as execution,
including any explicit runtime user override. It does not guess a username
from the hostname. Without root privileges or a selected non-root task user,
it logs why the repair was skipped.

The repair changes ownership to that task user and grants owner read/write
(and directory traversal), retaining existing ordinary execute permissions.
It skips symbolic links and hard-linked files. It does not make the whole
Python framework writable or change external applications such as MuMu.
Custom widget locations outside the managed tree are excluded. Logs report
changed, failed and skipped counts; a nonzero failure count needs attention.
This is a compatibility workaround for widgets that write beside their code;
it does not address simultaneous tasks replacing shared resource directories.
