Skip to content

Conversation

@MAJigsaw77
Copy link
Contributor

This pr makes it so it uses the working directory when searching for lime's path this mainly ensures that if theres a local lime installed, itll use the tools from that lime and not from the globally installed lime.

@player-03
Copy link
Contributor

Haven't tested this, but the code looks fine.

@tobil4sk
Copy link
Member

It seems like there are a lot of weird edge cases with how lime interacts with local .haxelib repositories, and it's starting to get a bit difficult to keep track of all the issues that have been fixed. To avoid regressions I think it might be worth looking into adding some basic tests to the lime repo that recreate some basic setups and ensure correct behaviour.

Before `Sys.setCwd()` would only be run in the `rebuild tools` case,
where it would always been cleaned up. The previous patch changed it so
that Sys.setCwd runs for all cases, even if it won't be cleaned up. This
patch corrects that error, and once again makes sure that setCwd is only
run for `rebuild tools`.
@tobil4sk
Copy link
Member

Prior to #1873, Haxelib.workingDirectory was set prior to running Haxelib.getPath, so this patch solves a regression (though, it does not occur with 8.2.3 because run.n hasn't been rebuilt).

Here is how to reproduce the issue:

  • set global haxelib repo to one without lime intsalled
  • run haxelib newrepo to create a local haxelib repository
  • install lime in the local repository with a dev path outside .haxelib's scope
  • rebuild run.n
  • run haxelib run lime test ...

@joshtynjala
Copy link
Member

it does not occur with 8.2.3 because run.n hasn't been rebuilt

Oops! Looks like we've overlooked that for a while now. I just added commit 49d81a6 to have GitHub Actions build run.n.

@tobil4sk
Copy link
Member

tobil4sk commented Oct 27, 2025

Oops! Looks like we've overlooked that for a while now. I just added commit 49d81a6 to have GitHub Actions build run.n.

We also need a way to keep the run.n checked into git up to date, otherwise run.n in git and haxelib releases might not be in sync and that can also cause confusion (I couldn't reproduce the issue with git until I recompiled run.n).

@joshtynjala
Copy link
Member

Ideally, run.n wouldn't be committed at all, and everyone who checked out the Lime repo would need to build it themselves like they need to rebuild the native binaries.

I don't think that there's a good way to keep run.n updated in the repo except to do it manually from time to time.

@player-03
Copy link
Contributor

I feel like it should be possible to automate somehow. We're just looking for PRs that touch RunScript.hx without touching run.n.

@joshtynjala
Copy link
Member

Checking for RunScript changes wouldn't catch hxp changes, but I guess if we caught RunScript changes, it might be easier to force a manual update using that as a mechanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants