[pull] main from com-lihaoyi:main #49
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
These cause issues once in a while, but in general Scaladoc bugs are outside of our control so it doesn't make sense to block PRs on them
# Pull Request Adds First Class Python Support [Web Examples] Part of #3928 ## Description Web Examples for Python `1-hello-flask`, `2-todo-flask`, `3-hello-django`, `4-todo-django` Examples ## Related Issues - Link to related issue #3928. ## Checklist - [x] 1-hello-flask - [x] 2-todo-flask - [x] 3-hello-django - [x] 4-todo-django - [x] Updated Documentation ## Status Require Review!!!
…2 support (#4178) JDK 22 introduced some changes to the method `System.console()`: > In JDK 22, System.console() has been changed to return a Console with enhanced editing features that improve the experience of programs that use the Console API. In addition, System.console() now returns a Console object when the standard streams are redirected or connected to a virtual terminal. Prior to JDK 22, System.console() instead returned null for these cases. This change may impact code that checks the return from System.console() to test if the JVM is connected to a terminal. If required, the -Djdk.console=java.base flag will restore the old behavior where the console is only returned when it is connected to a terminal. Starting JDK 22, one could also use the new Console.isTerminal() method to test if the console is connected to a terminal. Mill assumes the old behavior of `System.console` and use `System.console() != null` to check if we have interactive console, causing issue like #4161. This PR added universal availability check for an interactive console, compatible with JDK < 22 and later. SBT made similar changes in sbt/sbt#7843. Closes #4161 --------- Co-authored-by: Nikolay Artamonov <[email protected]>
…4127) This pr implements the examples for jslib/module. #3927 Key Changes: - handle usage of resources files in bundled and non-bundled environments - handle custom-resources usage - Standard resource files in `@<module-name>/resources` or custom resources files in user defined custom resource path can be imported globally`@<module-name>/resources-directory` - allows for access to resources defined in dependent modules - allows for access to resources in bundled code and environment - allows for access to resources define in `/test` - updated build script to handle multiple resources directories Implements Task generatedSources - imported via `@generated/generated-file-name` Note: For `example/javascriptlib/module/3-override-tasks/`, the foo directory needs to exist, hence the file `foo/readme.md`, code sources are generated from its .mill file ### Checklist - [x] **example/jslib/module** - [x] common-config/ - [x] resources/ - [x] custom-tasks/ - [x] override-tasks/ - [x] compilation-execution-flags/ - [x] executable-config
Fixes #4184 The basic problem is that we are spawning an `PumpedProcessInput` from the Mill server's redirected `stdin` to the stdin of any subprocess we spawn, but the `PumpedProcessInput`'s `InputPumper` thread only terminates on the source stream closing, and we never close the redirected `stdin` of the Mill server. Reading from the shared `stdin` from multiple tasks/threads concurrently doesn't really make sense, so we should probably not use `PumpedProcessInput` at all and just pass in a `DummyInputStream` with zero data. Interactive use cases like consoles and repl are handled by the `os.InheritRaw` codepath anyway and so won't be affected. `stdout`/`stderr` aren't affected, because having multiple tasks/threads writing lines to the same output stream is probably fine (although we could probably do a better job at ensuring it is done at a line-by-line granularity without splitting of lines between threads/tasks) Tested manually, ran the commands in the linked issue and verified that without this PR the leaked thread can be seen in `jstack`, but after this PR the leaked thread is no longer present This might also fix some of the cases where enter-on-rerun for `--watch` stops worked, perhaps because a leaked `InputPumper` is grabbing the `\n` character before it can be read by the `Watching.scala` logic
## Part of Android support ### Relevant issues: - #3868 - #3550 ### Outline - Follow android studio + gradle standard for directory structure - Unit test support (local runs - no android device needed) - Integration test support (android tests, needs an android device/emulator) ### New features - Ability to install an apk in the default available android device (tested against AVD) - Ability to run all integration tests with the install command (android manifest with instrumentation is needed, this needs to be a functionality of integration tests support in the future instead) - Classpath resolution (runtimeDependencies) for packaging with dependencies and user's source code (tested against integration test and running the android app itself via the emulator) - Special classpath resolution and packaging for android tests (integration tests) - Mill integrates with avdmanager, adb and emulator to automate the run of integration tests by creating virtual devices and controlling the emulator (start, stop). Examples are added in documentation of both kotlin and java app. This includes the ability to use different emulators for different apps, by specifying identifiers and ports, though this use case should be rare in app development lifecycles. - Github actions & mill support to run integration tests in (headless) emulator & differentiate from local mode (windowed emulator + default gpu settings) ### Github actions A sample repo to demonstrate what's needed to run the emulator https://github.com/vaslabs-ltd/test-android-emulator In the end what slowed me down was that for github actions, the AVD home env var was needed, which wasn't obvious until I've tested it in isolation . All the flags and kvm configs are also needed and it's what https://github.com/ReactiveCircus/android-emulator-runner does ### Stubs and missing features An effort was made to standardise the structure faster, so follow up PRs will not use a non-standard structure. Things that are working but not "production ready" are: 1. Integration tests debug apk: This inherits the current apk construction, debug functionality needs to be added and separated from the release androidApk task 2. No testOnly for integration tests: this is easy to do, but was not added in the interest of not increasing the size of the PR and the testing surface 3. Classpath resolution: For kotlin, jvm specific dependencies are removed in a hardcoded way. 4. Desugaring: This shows as a warning in the android tests apk creation, while the flow works, the d8 will need to be configured to desugar annotations properly. 5. Emulator CI mode only recognises github actions ### Demo #### Running android tests https://github.com/user-attachments/assets/0cb47ac7-32ff-4d5c-a678-11cd18807b10 --------- Co-authored-by: irodotos7 <[email protected]>
This PR improves `ktlint` support: it explicitly specifies the files to process. Without that current `mill.kotlinlib.ktlint.KtlintModule/checkFormatAll` run, for example, will go through the files under the `out` folder, which is useless and pollutes logs. Also this PR removes redundant flags from `reformatAll` and `checkFormatAll`: former will always be with `format=true` by definition, the latter will always be with `format=false`. Co-authored-by: 0xnm <[email protected]>
Co-authored-by: Li Haoyi <[email protected]>
The mac-latest and mac-13 workers seem significantly slower than the default linux worker, so just run a single thirdparty example as a smoketest on each one
…ral (#4386) Fixes #4373 This only affects people running clicking links or running commands manually to download the bootstrap scripts or example projects, or manually running `./mill init`, so it won't break any automated releases. This lets us substantially simplify the github actions workflows and build config
The Mill Client only forwards requests and therefore does not need much memory. However, Java doesn't know that an allocates a large heap based on the machines memory size. Therefore, give a way lower heap limit, creating a leaner client memory wise. Example on my machine: - Before: A Mill client reserved ~500MByte - After: A Mill client reserves the specified 24Mbyte This is mostly relevant for a long running mill client (examples `--watch` clients, `-i --no-build-lock` and --bsp`). Co-authored-by: Li Haoyi <[email protected]>
) ## This PR provides - ability to import a mill android project to android studio via BSP, including sources and generated sources. - necessary changes to the way sources are resolved (through module dependency instead of class inheritance). - Changes to tests (e.g. number of sources compiled) reflect these changes ### Not provided - Compilation still needs to be done from the command line in order for the paths to be resolved inside the IDE. Note that to make compilation, running, testing and debugging work from android studio, we'll need to develop a plugin for it ## Note This is an early draft and I need to cleanup or review a few rough edges, I submit this as a draft to get some early feedback. I've implemented java to get the basics to work, as kotlin has multiple kinds of sources and files that need to be taken care of, so this is just a small step. Don't hesitate to point out any issues as I've really just braced through and hacked around to get this to work! @0xnm @lihaoyi any feedback will be appreciated! ## Android Studio Integration The attempt focuses on BSP. Although bsp as a plugin does not seem to be available for android studio, it strangely becomes available if it is installed through intelliJ (see video) ### Basic changes - Use the moduleDeps instead of resolving the classpath bits (sources, resources) through inheritance. This makes BSP and studio integration work (see the directories that are highlighted correctly) - Crude implementation of bsp methods to get the IDE to report the imported modules correctly ### Tricky parts - Resources are compiled twice due to how aapt linking and later the module deps compile hierarchy. In order to avoid this, I've added an empty generatedSources method in android instrumentation module . ### Demo You can see in the demo most of the IDE static import features work (R is not recognised but I'll look into it either in this PR or subsequent). https://github.com/user-attachments/assets/77fe5e52-57e7-4480-9971-b50cc8d4d839 EDIT: I've fixed the R not being recognised and the kotlin import  EDIT 2: Added summary at the top
Like the title says, this option allows users of the `scalapb`-Plugin to submit the option `scala3_sources` to `scalapb` directly. --------- Co-authored-by: Björn Eyselein <[email protected]> Co-authored-by: Li Haoyi <[email protected]> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
…to 551dded8c6cc8a1054039c8bc0b8b48c51dfc6ef (#4384) Bumps [autofix-ci/action](https://github.com/autofix-ci/action) from ff86a557419858bb967097bfc916833f5647fa8c to 551dded8c6cc8a1054039c8bc0b8b48c51dfc6ef. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/autofix-ci/action/commit/551dded8c6cc8a1054039c8bc0b8b48c51dfc6ef"><code>551dded</code></a> Update README.md</li> <li>See full diff in <a href="https://github.com/autofix-ci/action/compare/ff86a557419858bb967097bfc916833f5647fa8c...551dded8c6cc8a1054039c8bc0b8b48c51dfc6ef">compare view</a></li> </ul> </details> <br /> Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Li Haoyi <[email protected]>
Now that joan38/mill-scalafix#225 is available
Resolves #3962 by extending `mill init` with the ability to import a Gradle project. * handles deeply nested modules * configures dependencies for configurations: * implementation / api * compileOnly / compileOnlyApi * runtimeOnly * testImplementation * testCompileOnly * configures testing frameworks * supports Gradle plugins * [java](https://docs.gradle.org/current/userguide/java_plugin.html) * [maven-publish](https://docs.gradle.org/current/userguide/publishing_maven.html) Additionally, Maven support added in #3756 was improved. * shared logic moved out to module `buildgen` * added support for BOM dependencies * eliminated creation of redundant test modules * fixed `millSourcePath` for test module --------- Co-authored-by: Li Haoyi <[email protected]> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
This was broken in the native image `dist/package.mill` refactor, which made the `dist` and `dist.native` modules depend on the upstream `build.runner` directly rather than using the `dist.assembly. This resulted in things like Thymeleaf logging tons of verbose DEBUG-level output when run in the `build.mill` file
also fix some selective test execution over-selection due to `millLastTag`
This PR allows users to define their own BOMs in Mill, as Mill modules, via a new `BomModule` type. `BomModule` inherits `JavaModule`, but has no sources and creates no JARs, only a POM. This PR also ensures one can publish `JavaModule`s that have no JAR, like is the case for `BomModule`. It adds non-regression tests illustrating various precedence rules of `BomModule` versus external BOMs (`bomIvyDeps`) and manual dependency management (via `depManagement`). Note that some cases might feel ambiguous - precedence rules could be changed later on if needed. --------- Co-authored-by: Tobias Roeser <[email protected]> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
…se together with Java and Scala examples (#4399) Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Motivation: Add some doc about the `MILL_TEST_RESOURCE_DIR`
This is from reviewing #4363. I couldn't comment on this because it was not part of the changes.
…mpiler` (#4406) It seems this class was renamed in https://youtrack.jetbrains.com/issue/KT-70221 Updated the unit test to exercise `2.1.0`, fails before this change, passes with. The existing kotlin versions seem to continue working AFAICT
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )