Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve development experience #813

Open
virzak opened this issue Feb 19, 2024 · 1 comment
Open

Improve development experience #813

virzak opened this issue Feb 19, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@virzak
Copy link
Contributor

virzak commented Feb 19, 2024

I'm trying to contribute to the repo, but was unable to find a way to do that.

Here are the steps I took:

  • Open the repository in code spaces
  • Make changes

How do I test before committing?

I tried to start Live Preview. I then changed the URL to curl -sS https://super-duper-rotary-phone-p66x959p45397g-3000.app.github.dev/shfmt | sh, but the result I got back was HTML.

There is some sort of url handler, but I have no idea how to invoke it.

The next thing I tried was yarn start and npm start hoping it would be easy to start a server with proper URL handling, but that was missing also.

Then i read more documentation and after realizing that packages were renamed to webi-installers ran the following:

$ node _webi/test.js ./pwsh
node:internal/modules/cjs/loader:1147
  throw err;
  ^

Error: Cannot find module './build-classifier/host-targets.js'
Require stack:
- /workspaces/webi-installers/_webi/builds-cacher.js
- /workspaces/webi-installers/_webi/builds.js
- /workspaces/webi-installers/_webi/test.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
    at Module._load (node:internal/modules/cjs/loader:985:27)
    at Module.require (node:internal/modules/cjs/loader:1235:19)
    at require (node:internal/modules/helpers:176:18)
    at Object.<anonymous> (/workspaces/webi-installers/_webi/builds-cacher.js:8:19)
    at Module._compile (node:internal/modules/cjs/loader:1376:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at Module.load (node:internal/modules/cjs/loader:1207:32)
    at Module._load (node:internal/modules/cjs/loader:1023:12)
    at Module.require (node:internal/modules/cjs/loader:1235:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/workspaces/webi-installers/_webi/builds-cacher.js',
    '/workspaces/webi-installers/_webi/builds.js',
    '/workspaces/webi-installers/_webi/test.js'
  ]
}

The clone command needs to include submodules. Alternatively they should be brought in later if, for example, git clone was donw by codespaces

git submodule update --init

On one of my machines I've been getting:

[INFO] getLatestBuilds: kubens
dbg: Installer User-Agent: win32/10.0.22621 x64/unknown libc
dbg: Installer Host Target:
{ errors: [], libc: 'libc' }
[INFO] getLatestBuilds: pwsh
C:\Code\webi-installers\_webi\serve-installer.js:68
    throw new Error(`OS could not be identified by User-Agent '${unameAgent}'`);
          ^

Error: OS could not be identified by User-Agent 'win32/10.0.22621 x64/unknown libc'
    at InstallerServer.helper (C:\Code\webi-installers\_webi\serve-installer.js:68:11)
    at C:\Code\webi-installers\_webi\test.js:85:42

Node.js v21.6.2

I needed to disable that line.

Now the message I'm getting is:

Do the scripts actually work?
        NEEDS MANUAL TEST: sh install-pwsh.sh
        NEEDS MANUAL TEST: powershell.exe install-pwsh.ps1

Perhaps it is my fault, but it took me a while to realize that the script actually created new files in the root directory.

Turns out it generated:

export WEBI_HOST='undefined'

Setting the variable before running node didn't help either, so I overwrote it manually.

Now I have a few options:

  • Test on host machine. I already have PWSH there and I don't want to remove it - no good
  • Spin a new container to test. Here is my output.
  🚀  podman run --name=pwsh_test --rm -it -v C:\Code\webi-installers\install-pwsh.sh:/tmp/install.sh docker.io/catthehacker/ubuntu:act-latest bash
root@d4f113f79c43:/tmp# WEBI_TAG=7.4.1
root@d4f113f79c43:/tmp# ./install.sh

>>> Welcome to Webi! - modern tools, instant installs.  <<<
    We expect your experience to be absolutely perfect!

    Success? Star it!   https://github.com/webinstall/webi-installers
    Problem? Report it: https://github.com/webinstall/webi-installers/issues
                        (your system is GNU/Linux/x86_64 with libc & curl+wget)
    Downloading https://webinstall.dev/packages/webi/webi.sh
        to ~/.local/bin/webi
Installing pwsh ...
    Found  ~/.local/bin

    Error: no 'pwsh@Unknown Tag' release for 'Unknown OS' (libc) on 'Unknown CPU' as one of 'exe,xz,tar,zip,git'

        Latest Version: v7.5.0-preview.1
        CPUs: armv7 aarch64 x86_64 x86
        OSes: linux darwin windows
        libcs: none musl
        Package Formats: .tar.gz .pkg .zip .msi
        (check that the package name and version are correct)

      Double check at undefined/api/releases/pwsh@.tab
          ?os=-&arch=-&libc=libc&formats=exe,xz,tar,zip,git&pretty=true

At this point I'm giving up.

What I think should happen is:

  • Open repo in locally or in a container (containers install all prerequisites such as shfmt automatically)
  • yarn && yarn start or npm install && npm start which spins a server where everything is configured and all that's needed to test would be to replace the host name
  • Ensure everything works and commit
@coolaj86
Copy link
Member

All your points are valid.

There's a lot of complexity, and some of it is beyond the essential complexity, out into accidental complexity territory.

It looks like I need to update the local testing process and documentation.

Originally the locally-generated installers were network-free, but a few months back I made some changes that inadvertently require network access to give some non-essential information - such as the current version of the software.

Rather than invest the time into solving that specific problem, I'd rather move forward with the roadmap to move the install process away from plugin-style functions and towards template generated installers.

... but I don't think I'm in a good place to dedicate that much time to it... so maybe the former is the better option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants