Leaving as draft, bintest fails on Windows, specifically non-windows binaries.

I checked, and this was true prior to archiver, so it's not specific to this PR, but I may as well fix it at the same time if I can.

On WSL, after moving to archiver, bintest succeeded with a handful of packages still.

Will resolve #18

This is a draft of the schema, you can add it to your IDE of choice that supports it. I will be adding some library that can ingest this schema and lint a given recipe via CLI as well.

I had minimized some of the JSON to decrease whitespace noise, but JetBrains had other ideas apparently... :sweat_smile:

Feel free to give early feedback, particularly for descriptions or if you can think of any odd validation the code does, as I've only looked through the code briefly to look for existing validation rules.

I noticed that you only have mappings for three OS, so let me know if you also want to limit the enum for ARCH in the schema. Currently it's just a list I put together from go tool dist list, although some obvious ones like wasm could probably be safely ignored.

This would also require a base URL for a given Gitea instance.

This may tie into #17 as well, since I'd imagine it would potentially get messy to add pkgs from various Gitea instances to the main pkg repo.

The only remaining question is how to deal with current windows setups.

Should we build in a migration system? In this case, a one-time scan for batch files and convert them to symlinks?

Hi @candrewlee14 , thank you for this project.

I have an ugly output on a Windows cmd shell (note: other apps output is managed well, even when using colors or other ANSI escape codes)

The best option would be fix this behaviour, but imho it is acceptable to allow user to disable the colored output. Cheers, Enrico

Pandoc (https://github.com/jgm/pandoc/releases/tag/2.19.2) has a couple tricky cases that I don't think we can currently handle.

• Different arch map for each OS
• MacOS has universal binary, so it doesn't use arch

I think it might be good to allow a filename_format_override and arch_map_override within each OS in os_map.

Closes #37

webman config - Base command allows changing top-level config, currently only the refresh interval webman config remove - Remove a package repository webman config add - Add a package repository

Part of me wants to be conservative and change add/remove to something like repo-add or another subcommand repo add But that would get a bit verbose, and I'm not sure it's worth the conservation currently.

Added support for decompressing tar.xz and tar.gz files, without exec(tar) Allows to unzip .tar files in windows

Details

• To decompress tar.gz the standard library is used
• To decompress tar.xz files, github.com/ulikunitz/xz was used, which is a 100% go library, it should work on a windows installation

test

• Linux (tar.gz, tar.xz)
• Windows (tar.gz)

Curlie works on windows, although the recipe needs to be modified, please add a related pull request

I'm running into an error installing a amd64 linux machine. Output:

curl https://raw.githubusercontent.com/candrewlee14/webman/main/scripts/install.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9690  100  9690    0     0   126k      0 --:--:-- --:--:-- --:--:--  126k
candrewlee14/webman info checking GitHub for latest tag
candrewlee14/webman info found version: 0.9.0 for v0.9.0/linux/x86_64
Refreshing package recipes for "webman"...
rename /home/candrewlee14/.webman/tmp/recipes/webman-pkgs-main /home/candrewlee14/.webman/recipes/webman: no such file or directory
webman: open /home/candrewlee14/.webman/recipes/webman/pkgs/webman.webman-pkg.yml: no such file or directory
Not all packages installed successfully

@jolheiser I think this has to do with the multi-repo configuration.

I am by no means a Powershell developer, but I was able to get something that works. The community can help improve if they run into any problems, but this is (hopefully) a good first pass.

Note that the screenshot points at my branch in my fork for testing, but I've adjusted it in the README.

Closes #16

At this point I fear this PR is rather large, so quick pretext that I am totally fine if you don't want all (or any) of this to be merged. Resolves #17

Some notable things this PR does:

1. Creates a config.yaml in the base .webman dir, which is used to control things like refresh interval and package repositories
   1. By default the refresh interval is set to 6h (same as current), and a single package repo is written (webman-pkgs)
   2. Recipes are moved one layer deeper and are identified by their name in the config.
      e.g. the default lives in ~/.webman/recipes/webman now
   3. When any commands are processed, they now look through package repos to find a match, meaning the first to match wins.
2. I ran gofumpt, which is why some of the formatting is changed. gofumpt is just a stricter gofmt, so they are compatible.
3. I removed the refresh files and am instead simply checking the directory modtime. Since we remove the entire dir, the modtime is effectively the same as the last time we "refreshed".
4. I removed some funcs/unnecessary syntax as I noticed them.

For me, personally, the reason for wanting this is because I have some homegrown projects that I would love to benefit from the UX simplicity of webman, but I'm not sure make sense to add to the central webman-pkgs repo.

As well, this allows me to potentially use this in a work setting where, again, the tools used may not make sense to add to the central location.

Currently there aren't any dedicated tests, so I will report back after using this for a while and let you know if I run into any hiccups. (And also when I find time I will try to write some tests)

Ironically both are editors, but nvim and helix both have issues with symlinks (at least on Windows) where they cannot find their runtime required files.

One potential fix is to also symlink their install from pkg/helix/helix-22.08.1 (example) to pkg\helix\current or perhaps pkg\helix\using .

At least with Helix you are able to override its runtime path, although I'm not sure about nvim.

This change allows you to use webman even if developer mode has not been enabled in windows:

if symlink creation fails, fallbacks to creating a script named ${executable name minus extension}.cmd.

Could impact #53 (and maybe #11) so, if you were interested in this, it would be necessary to correct the "Windows Symlink check" which I have left untouched right now.

Hi, i would like to use webman to install non-github/gitea software, eg Maven. To do this I created a new latest strategy (fixed, maybe you can find a better name). An example of a working recipe definition is in testcases/pkgs/maven.webman-pkg.yml.

go run main.go -l testcases add maven

Cheers, Enrico

• Add some comments
• Move some code to other files for clarity
• Add group schema
• Fix stem parsing for packages with hyphens in their name

Open to feedback while I work on it! 🙂

When package schema changes without backwards compatibility, webman should be able to notify the user that webman is out of date, and then install the package from a commit of webman-pkgs that was compatible (instead of erroring out trying to install an invalid new schema).

This could be something like a compatibility.yml in the root of webman-pkgs:

webman_versions:
  - v0.8.0: [last compatible webman-pkgs commit SHA]
  - v0.9.0: [last compatible webman-pkgs commit SHA]

and an unspecified end would use the latest commit.