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
From the maintainer Li Haoyi: I'm putting a 500USD bounty on this issue, payable by bank transfer on a merged PR implementing this.
The various Jvm.* methods are a mess. #3770 makes them marginally more messy, but they've been messy for years and could use a cleanup.
The goal of this issue is to consolidate all subprocess and classloader spawning operations in Jvm.scala into (approximately) the following four signatures
Jvm.spawn and Jvm.call intentionally follow the signatures of os.spawn and os.call. Jvm.spawnClassloader and Jvm.callClassloader are in-memory variations of the theme, with no subprocess-related parameters and an API tweaked to work in-memory.
All existing subprocess/classloader APIs in Jvm.scala should be refactored to go through the four APIs above. The other APIs should all be deprecated.
All code outside Jvm.scala spawning subprocesses or classloaders should go through those four APIs,
We should ensure all tests pass both with and without change (2) above to ensure that the behavior of the existing methods is maintained (at least as far as they are covered by Mill's existing test suite)
The text was updated successfully, but these errors were encountered:
Related to com-lihaoyi#3772
Refactor `Jvm.scala` to consolidate subprocess and classloader spawning operations into four specified signatures.
* **Refactor `callSubprocess` method:**
- Rename to `call`.
- Update parameters to match the specified `call` signature.
- Use `jvmCommandArgs` to generate command arguments.
- Call `os.call` with the updated parameters.
* **Refactor `runSubprocess` method:**
- Rename to `spawn`.
- Update parameters to match the specified `spawn` signature.
- Use `jvmCommandArgs` to generate command arguments.
- Call `os.spawn` with the updated parameters.
* **Add `spawnClassloader` method:**
- Create a new method to match the specified `spawnClassloader` signature.
- Use `mill.api.ClassLoader.create` to create a classloader.
* **Add `callClassloader` method:**
- Create a new method to match the specified `callClassloader` signature.
- Use `spawnClassloader` to create a classloader and set it as the context classloader.
- Execute the provided function with the new classloader and restore the old classloader afterward.
* **Add tests in `JvmTests.scala`:**
- Add tests for the new `call` method.
- Add tests for the new `spawn` method.
- Add tests for the new `callClassloader` method.
- Add tests for the new `spawnClassloader` method.
From the maintainer Li Haoyi: I'm putting a 500USD bounty on this issue, payable by bank transfer on a merged PR implementing this.
The various
Jvm.*
methods are a mess. #3770 makes them marginally more messy, but they've been messy for years and could use a cleanup.The goal of this issue is to consolidate all subprocess and classloader spawning operations in
Jvm.scala
into (approximately) the following four signaturesJvm.spawn
andJvm.call
intentionally follow the signatures ofos.spawn
andos.call
.Jvm.spawnClassloader
andJvm.callClassloader
are in-memory variations of the theme, with no subprocess-related parameters and an API tweaked to work in-memory.Jvm.scala
should be refactored to go through the four APIs above. The other APIs should all be deprecated.Jvm.scala
spawning subprocesses or classloaders should go through those four APIs,The text was updated successfully, but these errors were encountered: