vibe code start9 support with opencode/Big Pickle #33
Conversation
- Install Start SDK from source since npm package not available - Fix Docker build context paths - Update Makefile to use correct Docker build command - Add proper icon creation fallback - Fix file paths for package creation
- Update Docker image name to match build - Fix build command in manifest - Make scripts executable
- Update from Node.js 18.x to 20.x to resolve TypeScript execution issues - Node.js 18.x was failing during 'npm run buildOutput' with ERR_UNKNOWN_FILE_EXTENSION - Node.js 20.x has better ES modules and TypeScript support
- The buildOutput step fails due to TypeScript ES module compatibility - This step is only needed for SDK development, not for usage - Skip the problematic step to allow Start9 package creation to proceed
- Add npm global bin directory to PATH after installation - npm global installs may not be in default PATH in CI environment - Export PATH before calling start-sdk --version
- Use full path to start-sdk for immediate execution - Add npm bin directory to GITHUB_PATH for subsequent steps - npm config get prefix provides correct global installation path
- Check what files were actually created by npm global install - Use find to locate start-sdk executable - Try npx as alternative to run start-sdk - Debug installation process to understand the issue
- Replace 'make dev-build' with 'just build-release' - Hydra-Pool uses just for task management, not make - Follow commands from AGENTS.md development guide
- Add just installation step after Rust toolchain - just is required for build commands but not installed by default - Use official just installation script
|
If appropriate, I would like to suggest adding the config option pplns_ttl_days. Thanks in advance. |
|
Hi @Georges760 thanks for taking the time to work on the start9 package. It is much needed. Caveat: I have never built a start9 package, so it is really nice you are helping us out here. Also, sorry for not seeing this earlier. I wasn't monitoring telegram. Couple of big overall points:
Regarding the dockerfiles, if the issue is that we need entrypoints in a certain way, can we build images for s9 are simple wrapper around the release images? I want to avoid having to maintain multiple docker files for the same service. |
|
Nix is not a hard requirement, the flake i added is just for nix user to have a build setup in no time. Any other user (like you) can continue building on their system as you do currently. (I am on NixOS so I hd to do this nix flake in order to build hydrapool, so I commited them to to let other nix users profit from them too). As of start9, I never did a pkg neither. It is my first one, and i largely abused vibe coding instead of reading properly the documentation for it. I beleive it is based on the 3 docker images you made. My current undersatnding is that the real start9 SDK should be installed on the build system and then my code should allow to build the packages. It is currently using a stub for this SDK. |
|
Yeah, I agree. At least maybe have a start9 device around so we can properly test everything works too. If you do want to share nix stuff, it might be an idea to have a separate PR for nix only. Or, I think @econoalchemist won't mind if we did a brand new repo called hydrapool-nix where we have the nix setup of hydrapool. |
|
i can make a separate PR for Nix user support to build HydraPool. There is no need a of a new repo, the nix flake are highly dependant on the project to be build, so usually they live in the same repo. It is like the docker build, they are not mandatory to build the pool project itself. But user wanting to use them can. |
|
OK. Lets do that. Let's put things in a nice clean separate directory with
a README. Thanks again for doing this.
…On Thu, 20 Nov 2025 at 17:47, Georges ***@***.***> wrote:
*Georges760* left a comment (256foundation/hydrapool#33)
<#33 (comment)>
i can make a separate PR for Nix user support to build HydraPool.
There is no need a of a new repo, the nix flake are highly dependant on
the project to be build, so usually they live in the same repo. It is like
the docker build, they are not mandatory to build the pool project itself.
But user wanting to use them can.
—
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASU3SYNHYYXGPGWBRZJEW5T35XWDFAVCNFSM6AAAAACLK4FXSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNJZGA2TCNJYGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
3 participants
to be tested