You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pesde-tooling doesn't do anything special, so you should just be able to run the tool you want as usual with process.spawn and setup will be handled automatically.
Do note that the process stderr might contain warnings or installation progress bars from pesde-tooling.
@CompeyDev I think the issue is valid. The OP is proposing to expose a library API for the tooling packages so that another Lune process doesn't have to get spawned while they're already in a Lune process. In my opinion that's a good addition.
Oh! In that case, pesde/toolchainlib already exposes a runTool method, to which you can supply the ToolId of the tool you want to execute. For example, to run Rojo:
toolchainlib.runTool({
alias=Option.None,
repo="rojo-rbx/rojo",
version=Option.None-- defaults to latest
})
If you want to avoid spawning a separate lune process altogether, you can do:
I think having the individual tooling packages expose a library export might be more fitting, though. Would allow user to avoid the direct dependency on toolchainlib as well as not having the versions desync (latest being different from the lockfile, for example).
I wouldn't be fully opposed to that, but this is usually only useful if you don't already depend on the tool as a separate binary dependency; so the version desync shouldn't be an issue.
Well, pesde allows you to have both library and binary exports, so you get the benefits in 1 go. Having a library export is useful for setups like Darklua + Rojo where it is common to have a script that runs Darklua to process files, Rojo to generate a sourcemap (for Luau LSP) and a serve session.
Recently, a few changes were made to our versioning system for packages: see CHANGELOG.md.
This introduces some challenges with library exports, as we technically have "breaking" changes, which are related to supported runtime versions as build metadata bumps. This may be tolerable for our binaries so as the caveat is well documented, but absolutely intolerable in the case of libraries. We should reconsider if this feature is feasible given the changes in our circumstances.
Activity
daimond113 commentedon Feb 2, 2025
The pesde repo is for pesde itself, the tooling is a separate repository. I'll transfer this issue there.
CompeyDev commentedon Feb 2, 2025
pesde-toolingdoesn't do anything special, so you should just be able to run the tool you want as usual withprocess.spawnand setup will be handled automatically.Do note that the process stderr might contain warnings or installation progress bars from
pesde-tooling.daimond113 commentedon Feb 2, 2025
@CompeyDev I think the issue is valid. The OP is proposing to expose a library API for the tooling packages so that another Lune process doesn't have to get spawned while they're already in a Lune process. In my opinion that's a good addition.
CompeyDev commentedon Feb 2, 2025
Oh! In that case,
pesde/toolchainlibalready exposes arunToolmethod, to which you can supply theToolIdof the tool you want to execute. For example, to run Rojo:If you want to avoid spawning a separate lune process altogether, you can do:
daimond113 commentedon Feb 2, 2025
I think having the individual tooling packages expose a library export might be more fitting, though. Would allow user to avoid the direct dependency on toolchainlib as well as not having the versions desync (latest being different from the lockfile, for example).
CompeyDev commentedon Feb 2, 2025
I wouldn't be fully opposed to that, but this is usually only useful if you don't already depend on the tool as a separate binary dependency; so the version desync shouldn't be an issue.
daimond113 commentedon Feb 2, 2025
Well, pesde allows you to have both library and binary exports, so you get the benefits in 1 go. Having a library export is useful for setups like Darklua + Rojo where it is common to have a script that runs Darklua to process files, Rojo to generate a sourcemap (for Luau LSP) and a serve session.
CompeyDev commentedon Sep 24, 2025
Recently, a few changes were made to our versioning system for packages: see CHANGELOG.md.
This introduces some challenges with library exports, as we technically have "breaking" changes, which are related to supported runtime versions as build metadata bumps. This may be tolerable for our binaries so as the caveat is well documented, but absolutely intolerable in the case of libraries. We should reconsider if this feature is feasible given the changes in our circumstances.