Motivation: updating a machine fails, if it depends on a private github repo, as the remote will likely not be authenticated.
This adds a new flag `--fetch-local` to `clan machines update` which fetches all flake inputs prior to building, then uploads them to the build-host.
This also adds a new error message, when flake inputs could not fetched, to hint the user to use `--fetch-local`
Fix clan template creation when already in a flake.
Currently we already fail with very clear and descriptive error when
trying to evaluate the template of the flake we are in:
```
Failed to select template 'flake-parts' from flake '/tmp/superclan' (via attribute path: /tmp/superclan#clanInternals.templates.clan."flake-parts")
```
This is undesired behavior.
When we are trying to create a clan with `clan flakes create`.
We can't rely on the fact that the flake we are currently in exports flake templates.
Now we *try* to evaluate the flake we are in upon creation.
If there are no clan templates available, we now will fall back to
builtin templates.
Closes: #4472
Allow `clan templates list` to function outside a clan.
Currently when bootstrapping a clan and trying to list the templates
it fails as follows:
```
Traceback (most recent call last):
File "/nix/store/pkrsr8zr90bps1fwrl8n74zbb9g038b8-clan-cli/bin/.clan-wrapped", line 9, in <module>
sys.exit(main())
~~~~^^
File "/nix/store/pkrsr8zr90bps1fwrl8n74zbb9g038b8-clan-cli/lib/python3.13/site-packages/clan_cli/cli.py", line 516, in main
args.func(args)
~~~~~~~~~^^^^^^
File "/nix/store/pkrsr8zr90bps1fwrl8n74zbb9g038b8-clan-cli/lib/python3.13/site-packages/clan_cli/templates/list.py", line 11, in list_command
templates = list_templates(args.flake)
File "/nix/store/pkrsr8zr90bps1fwrl8n74zbb9g038b8-clan-cli/lib/python3.13/site-packages/clan_lib/templates/__init__.py", line 20, in list_templates
custom_templates = flake.select("clanInternals.inventoryClass.templatesPerSource")
^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'select'
```
With the change we get the following output:
```
Available 'clan' templates
├── <builtin>
│ ├── default: Initialize a new clan flake
│ ├── flake-parts: Flake-parts
│ └── minimal: for clans managed via (G)UI
Available 'disko' templates
├── <builtin>
│ └── single-disk: A simple ext4 disk with a single partition
Available 'machine' templates
├── <builtin>
│ ├── flash-installer: Initialize a new flash-installer machine
│ └── new-machine: Initialize a new machine
```
Allowing to check for available templates without needing to have a
clan, which improves the bootstrapping experience.
- Replace Tor-specific implementation with generic SOCKS5 proxy support
- Change `tor_socks` boolean to `socks_port` and `socks_wrapper` parameters
- Move Tor functionality to clan_lib.network.tor submodule
- Add connection context managers to NetworkTechnologyBase
- Improve network abstraction with proper remote() and connection() methods
- Update all callers to use new SOCKS5 proxy interface
- Fix network ping command to properly handle connection contexts
This allows for more flexible proxy configurations beyond just Tor,
while maintaining backward compatibility for Tor usage.
This should better be fixed with types. It should be possible to initialize a flake from a Path, making it very clear that a path `foo` is meant and not a remote flake called `foo`
Previously, paths like /nix/store/hash-file.nix:123 were incorrectly
treated as pure store paths and wrapped in {"outPath": ...}, breaking
the cache. This fix:
- Adds helper functions to properly detect and handle store references
- Distinguishes between pure store paths and paths with metadata (line numbers)
- Supports multiple store references in a single string
- Handles custom NIX_STORE_DIR correctly
- Ensures existence checks work for all store references
Also fixes test_cache_gc to delete NIX_REMOTE for proper local store testing.
This adds a (for now hidden) clan network command that exposes list,
ping, overview subcommands to get informations about configured
networks.
ClanServices can now use the exports to define network specific
information.
This is not the complete feature yet, as we are lacking more tests and
documentation, but merging this now makes it easier to iterate.
