Some projects don't have a tool as their primary project or might publish multiple tools from the same repository.

It would be useful to be able to declare dependencies on these, maybe like:

[tools]
genref = { source = "rojo-rbx/rbx-dom/generate-reflection", version = "1.2.6" }

We would probably need a special convention for tags to make this kind of detection feasible, like generate-reflection-v1.2.6. I've been following this in the rbx-dom repository and it seems to work fairly well.

If you install Rojo via Foreman...

[tools]
rojo = { source = "rojo-rbx/rojo", version = "0.6.0-alpha.1" }

and then run rojo --help, you'll see that Rojo knows that its executable name is weird:

Rustup solves this by keeping the executable names the same, but putting them into subfolders. We should adopt that strategy, too!

I'm attempting to start a nevermore project that uses foreman.toml to fetch its specific tools. I am on Windows 11 and I built foreman from source using cargo. My foreman.toml file looks like this:

[tools]
rojo = { source = "quenty/rojo", version = "=7.0.0-quenty-npm-canary.3" }
run-in-roblox = { source = "rojo-rbx/run-in-roblox", version = "0.3.0" }
selene = { source = "Kampfkarren/selene", version = "0.14.0" }

Running foreman install succeeds, but when I restart my shell and attempt to run these commands they all return the same output, and none of the subcommands for their respective tools work.

For some reason, I have foreman installed, but the 'wally' command does not seem to work. Any ideas on how to fix this?

Right now, Foreman just picks the first artifact that has the name of your platform in it.

Some software like ripgrep has releases with lots of artifacts. For this release, 11.0.2, there are four Windows releases alone:

1. ripgrep-11.0.2-i686-pc-windows-gnu.zip
2. ripgrep-11.0.2-i686-pc-windows-msvc.zip
3. ripgrep-11.0.2-x86_64-pc-windows-gnu.zip
4. ripgrep-11.0.2-x86_64-pc-windows-msvc.zip

On my system, the ideal choice would be artifact 4, because it is 64-bit and compiled for MSVC, my preferred compiler.

We should change the artifact-choosing algorithm to extract "attributes" from an artifact based on its name. From there, we can rank artifacts and choose the best one for our platform. Some attributes we might pick include:

1. Platform, like Windows or macOS
2. Architecture, like i686/x86/32, x86_64/x64/64, arm, or aarch64
3. Toolchain, like MSVC, GNU or MUSL

If an inner project specifies a different version of a tool than an outer project (or the user's global Foreman config), then running foreman install will only install the inner version of that tool.

It might be a good idea to install all versions!

I recently became the owner of the foreman crate on crates.io.

Alex requested that the first version I publish be 1.0! If he does a re-launch of what is currently known as foreman, we'll add a notice to the README pointing to the new project for anyone looking for it.

These two tools should be the same, but currently aren't:

[tools]
rojo = { source = "ROJO-RBX/ROJO", version = "0.5.0" }
rojo2 = { source = "rojo-rbx/rojo", version = "0.5.0" }

It's probably safe to force sources to be lowercase. Alternatively, we could wrap them in a newtype wrapper whose Hash implementation transforms each character to be lowercase first.

When running foreman install no feedback is truly given as an output, which makes it hard to tell if anything happened. A summary of changes, or output saying nothing changed would be optimal.

Latest foreman release at the time of writing in 1.3.0. However 'cargo install foreman' still installs version 1.1.0. Looking at the crates the latest one available is still 1.1.0.

Can the foreman crates be updated?

#30 moved the structopt initialization logic above the tool detection code, which means that Foreman now eats all command line arguments for the tools it tries to installs. As such, it doesn't work anymore at all!

This line can't be the first thing that runs:

The very recent v1.0.3 foreman release doesn't include binaries, which breaks any CI scripts that make use of foreman releases.

For supporting setup-foreman, it would be useful to have a command to update ~/.foreman/auth.toml with a GitHub PAC.

I can't install foreman because cargo keeps giving this error

Spawning a long running process in the terminal such as rojo serve and hitting Ctrl+C does not properly kill the process, it just leaves it hanging. This means that commands that bind to an address, such as the above, will not work at all after the first run.
I'm getting this issue using foreman v1.0.3 and macOS 12.3 on an M1 MacBook Pro 14''.

I was told that applying a patch similar to this one (LPGhatguy/aftman@1842a95) would solve the issue, however it seems like foreman already uses CommandGroup (since 7a037d9) so this might be a separate issue 🤔

A workaround for now is to use something like Activity Monitor, find and force-kill the spawned process, or to reboot.

Edit:

I had a suspicion that it might have been because of my shell (nushell) so I went and checked bash, zsh, fish, and they all behave the same. I also tried different terminals with each: VSCode built-in, hyper, terminal.app, same behavior for all there as well.

I did a fresh install of foreman on Ubuntu and Debian (both WSL) and it seems like the TOML parser is adding a caret to the version string causing the Github release matching to fail, here's the trace https://pastebin.com/shFReDkt.

Works fine on Windows with the same foreman.toml.

I don't know if this is because I am running it in the WSL or if its for all Linux systems

Steps to reproduce

• New Linux system with cargo
• cargo install --git https://github.com/rojo-rbx/foreman.git
• foreman list
• uncomment rojo in ~/.foreman/foreman.toml
• foreman install

after running foreman install with the following line in my foreman.toml file:

wally = { source = "UpliftGames/wally", version = "0.3.1" }

wally isn't recognized after command, even though running the foreman list command lists wally as an installed tool

is there a permission issue I'm missing? I don't know where the wally folder is (if it was even created). also I'm on apple silicon, M1 Pro chip

Right now, users on MacOS and Linux unzip the release, but the binary isn't marked as executable. Use a platform-appropriate archiver that retains the correct file bits.

My team relies on several tools that are located in private repositories (Rotriever is one example), and because my team intends to make our projects source-available, this leads to regular users being unable to install public tools like Rojo, Selene, and StyLua due to an authentication error.

Foreman should process every tool and only error at the end if there were any tools it could not install. This will ensure all public tools will be installed.

Got a new Mac with the M1 processor. Successfully installed foreman and did forman install and it seemed to work installing Rojo. However, if I then run rojo, I get:

zsh: command not found: rojo

Not sure why it's not picking it up; if I look in the foreman/tools folder in home, I can see she did install it. Any hints?

None of the tools I've installed work. Foreman runs perfectly fine. When I run foreman list, all of the tools show up. However when I type something like rojo --version, I get this error

rojo : The term 'rojo' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and 
try again.
At line:1 char:1
+ rojo
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (rojo:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

forman.toml:

[tools]
rojo = { source = "rojo-rbx/rojo", version = "7.2.1" }
selene = { source = "Kampfkarren/selene", version = "0.21.1" }
stylua = { source = "JohnnyMorganz/StyLua", version = "0.14.3" }
wally = { source = "UpliftGames/wally", version = "0.3.1" }

foreman list:

Installed tools:
  rojo-rbx/rojo
    - 7.2.1
  JohnnyMorganz/StyLua
    - 0.14.3
  Kampfkarren/selene
    - 0.21.1
  UpliftGames/wally
    - 0.3.1

Version: 1.0.5
Installation method: Rust
What I've done: Reinstalled Foreman, checked to make sure the path variable was correct, and reinstalled the tools many times.

Foreman currently assumes you're on Windows and assumes artifacts are zip files with win64 in their name somewhere and only one file. This doesn't hold up for projects that aren't mine, mostly.

We should support:

• Other platforms... at all
• Artifacts with different platform names
  • windows, win32, win64 for Windows
  • macos, darwin for macOS
  • linux for Linux?
• Artifacts with different structure
  • plain binaries
  • zip files with more than one file in them

Currently, if you mis-configure foreman.toml (with a syntax error like a missing quotation mark), foreman spits a rather cryptic error message instead of spitting out something that's easy to understand:

It'd be ideal if foreman spit out an error message along the lines of "Error while reading configurations : There is a syntax error on line n!" or somesuch.

Just like #85, the cargo crate is out of date.

It might be possible for a project using Foreman to replace a commonly used tool like Rojo with a binary from a different source that could be malicious.

Do we think it's a concern that running rojo in a freshly-cloned directory could execute arbitrary code?

One possible guard would be needing to 'trust' any new source that tools are downloaded from. The first time a user tries to run a tool from rojo-rbx/rojo, Foreman would ask if it's okay.

On CI machines, we could add a flag like --always-trust-sources that lets us bypass this prompt.

Currently, as of version 1.0.2, foreman does not install the proper versions of tools. It will instead install the latest version of the tool, completely ignoring the specified version in foreman.toml.
As you can see in the screenshot below, even though rojo 6.0.0-rc.1 is specified, 6.0.0-rc.4 gets installed instead. With remodel, instead of 0.7.0 being installed, 0.7.1 gets installed. 6.0.0-rc.4 and 0.7.1 are both the latest versions of rojo and remodel, respectively.

Foreman currently doesn't track what caused a tool to be installed, only that it's installed.

We can introduce a command to uninstall individual tools, but some sort of garbage collection command might be useful for deleting old stuff.

Explicitly upgrading tools to the maximum allowed by SemVer would be a useful operation.

It has been a high point of friction getting other lua engineers onboarded with Foreman due to the manual process of updating their PATH to include the bin folder.

In particular, it is cumbersome to have to provide Windows and MacOS specific instructions any time I want to include Foreman in a project due to the varying ways of configuring the user's PATH. I have personally had a lot of trouble in the past figuring out just how to setup MacOS with the zsh shell so that it knows where the bin folder is.

It would be great if the PATH could be configured automatically so that my team can have a frictionless experience when installing tools managed by Foreman. Our lives would be a lot easier if this were the case.

It appears as though the Mac 1.0.2 release isn't a DMG or executable file. Can you tell me how to install Foreman on Mac please?

I'm currently using a unix operating system, and the terminal uses the .zshrc type; I'm trying to add the two paths that are ~/.foreman/bin & ~/Documents/Foreman, I did a similar process on Windows; which was called 'Environmental Variables', which wasn't as much of a endeavour process as this one. Any help would be appreciated, thanks!

Foreman makes copies of itself with different names to act as proxies to installed tools. I took this idea from how Rustup proxies tools from the Rust toolchain.

If a user updates Foreman (or is working on Foreman...), sometimes old versions of the tool end up getting run, which isn't fun. We should figure out a way to either update these links to alleviate the problems they cause.

After installing remodel, McAfee apparently warned me that foreman's executable was a virus. I installed foreman via cargo.

I think this is incorrect as there's no trace of malicious code in foreman...

I want the .foreman folder to be somewhere else rather than my user home folder.

Is it possible to have foreman listening to an environment variable as to where placing it's .foreman folder?

Sometimes, it's useful for projects to depend on versions of a tool that isn't managed by Foreman. This comes up when working on tools like Rojo, where I want to use the master branch by default, not any stable release.

To solve this, we could add path dependencies to Foreman, like:

[tools]
rojo = { path = "~/.cargo/bin/rojo" }

Are there any security concerns with this approach? Being able to run any binary on a user's system might be dangerous, and we might want to lock this down to the system config only.

I would love to see Foreman as a Chocolatey package! If possible? I don't know if that goes against distribution.

This would make the whole install process much more straight forward (Even know its pretty simple already haha)

For example running choco install foreman would install it and add it to your PATH automatically!
Then you could run foreman install and that would automatically add any of the tools to your path as well.

In a perfect world I would modify it and move the .foreman folder to the chocolatey install directory instead. Then I would have Foreman add any new tools into the bin folder of chocolatey instead of the bin folder for Foreman. If anyone would like to help I would love that!

foreman installed by cargo install and direct download from release page would disappear after running foreman list. The foreman list command also errors out. See detailed errors below. This is run on a Windows x64 laptop via Powershell. This doesn't seem to be an issue with second-latest release.

I didn't try other commands, not sure this bug only happens for foremanl list, or other commands as well.

This bug doesn't happen for version 1.0.5.

C:\Users\XXX\.cargo\bin> ls

    Directory: C:\Users\XXX\.cargo\bin

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/9/2023  3:18 PM       10077696 cargo-clippy.exe
-a---            1/9/2023  3:18 PM       10077696 cargo-fmt.exe
-a---            1/9/2023  3:18 PM       10077696 cargo-miri.exe
-a---            1/9/2023  3:18 PM       10077696 cargo.exe
-a---            1/9/2023  3:18 PM       10077696 clippy-driver.exe
-a---           1/10/2023  4:50 PM        5712896 foreman.exe
-a---            1/9/2023  3:18 PM       10077696 rls.exe
-a---            1/9/2023  3:18 PM       10077696 rust-gdb.exe
-a---            1/9/2023  3:18 PM       10077696 rust-gdbgui.exe
-a---            1/9/2023  3:18 PM       10077696 rust-lldb.exe
-a---            1/9/2023  3:18 PM       10077696 rustc.exe
-a---            1/9/2023  3:18 PM       10077696 rustdoc.exe
-a---            1/9/2023  3:18 PM       10077696 rustfmt.exe
-a---            1/9/2023  3:18 PM       10077696 rustup.exe

C:\Users\XXX\.cargo\bin> foreman list
ResourceUnavailable: Program 'foreman.exe' failed to run: Access is denied.At line:1 char:1
+ foreman list
+ ~~~~~~~~~~~~.
C:\Users\XXX\.cargo\bin> ls

    Directory: C:\Users\XXX\.cargo\bin

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/9/2023  3:18 PM       10077696 cargo-clippy.exe
-a---            1/9/2023  3:18 PM       10077696 cargo-fmt.exe
-a---            1/9/2023  3:18 PM       10077696 cargo-miri.exe
-a---            1/9/2023  3:18 PM       10077696 cargo.exe
-a---            1/9/2023  3:18 PM       10077696 clippy-driver.exe
-a---            1/9/2023  3:18 PM       10077696 rls.exe
-a---            1/9/2023  3:18 PM       10077696 rust-gdb.exe
-a---            1/9/2023  3:18 PM       10077696 rust-gdbgui.exe
-a---            1/9/2023  3:18 PM       10077696 rust-lldb.exe
-a---            1/9/2023  3:18 PM       10077696 rustc.exe
-a---            1/9/2023  3:18 PM       10077696 rustdoc.exe
-a---            1/9/2023  3:18 PM       10077696 rustfmt.exe
-a---            1/9/2023  3:18 PM       10077696 rustup.exe

Remodel has a cool logo, Foreman should have one too!

This file doesn't exist by default. We should create one with a useful comment if it doesn't exist!

It may be difficult to notice that you're overriding a definition. Foreman should warn or error when duplicate version of a tool are specified using the same key.