PublishModule

Miscellaneous machinery around traversing & querying the build hierarchy, that should not be needed by normal users of Mill

Metadata about your project, required to build and publish.

This is roughly equivalent to what you'd find in the general section of a pyproject.toml file https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#about-your-project.

The artifact version that this module would be published as.

Files to be included in the directory used during the packaging process, apart from pyproject.

The format is ->. Where `` is relative to some build directory, where you'll also find src and pyproject.toml.

Validate artifacts with a dry-run uv publish.

The direct dependencies of this module. This is meant to be overridden to add dependencies.

Publish the sdist and wheel to the package repository (index) defined in this module.

You can configure this command with uv's UV_PUBLISH_* environment variables or equivalent MILL_UV_PUBLISH_* variables. For example:

MILL_UV_PUBLISH_URL=https://test.pypi.org/legacy/

All artifacts that should be published.

SPDX license expression written to the package metadata. Override this when publishMeta.license does not use an SPDX identifier.

Import package built into the distribution. By default, uv_build derives this from the normalized distribution name. Override this when the name used in import statements differs from publishMeta.name.

Import packages built into the distribution.

The readme file to include in the published distribution.

The repository (index) URL to publish packages to.

The content of the PEP-518-compliant pyproject.toml file, which describes how to package this module into a distribution (sdist and wheel).

By default, Mill will generate this file for you from the information it knows (e.g. dependencies declared in pythonDeps and metadata from publishMeta). It will use uv_build as the build backend, and uv build as the frontend.

You can however override this task to read your own pyproject.toml file, if you need to. In this case, please note the following:

• Mill will create a source distribution first, and then use that to build a binary distribution (aka wheel). Going through this intermediary step, rather than building a wheel directly, ensures that end users can rebuild wheels on their systems, for example if a platform-dependent wheel is not available pre-made.

• Hence, the source distribution will need to be "self contained". In particular this means that you can't reference files by absolute path within it.

• Mill creates a "staging" directory in the sdist task, which will be used to bundle everything up into an sdist (via uv build, although this is an implementation detail). You can include additional files in this directory via the buildFiles task.

Bundle everything up into a source distribution (sdist).

Build a binary distribution of this module.

The repositories used to resolve dependencies

Unlike repositoriesTask, this includes the Mill internal repositories, which allow to resolve Mill internal modules (usually brought in via JavaModule#coursierDependencyTask).

Beware that this needs to evaluate JavaModule#coursierProject of all module dependencies of the current module, which itself evaluates JavaModule#mvnDeps and related tasks. You shouldn't depend on this task from implementations of mvnDeps, which would introduce cycles between Mill tasks.

Bind a dependency (Dep) to the actual module context (e.g. the scala version and the platform suffix)

Bundles the project into a self-contained native PEX SCIE executable.

Command-line options to pass as bundle configuration defined by the user.

Whether to enable Gradle Module support when fetching dependencies

Opens up a Python console with your module and all dependencies present, for you to test and operate your code interactively.

Customize the coursier file cache.

This is rarely needed to be changed, but sometimes e.g. you want to load a coursier plugin. Doing so requires adding to coursier's classpath. To do this you could use the following:

 override def coursierCacheCustomizer = Task.Anon {
    Some( (fc: coursier.cache.FileCache[Task]) =>
      fc.withClassLoaders(Seq(classOf[coursier.cache.protocol.S3Handler].getClassLoader))
    )
 }

A CoursierModule.Resolver to resolve dependencies.

Can be used to resolve external dependencies, if you need to download an external tool from Maven or Ivy repositories, by calling CoursierModule.Resolver#classpath.

The name of the default command, which will be automatically executed if the module name is provided at the Mill command line.

Any environment variables you want to pass to the forked Env

Folders containing source files that are generated rather than handwritten; these files can be generated in this task itself, or can refer to files generated from other tasks

Base URLs of Python package indexes to search, in priority order. The final URL is passed to uv as its lowest-priority default index.

Optional custom Java Home for the JvmWorker to use

If this value is None, then the JvmWorker uses the same Java used to run the current mill instance.

The directories used to construct the PYTHONPATH for this module, used for execution, excluding upstream modules.

This includes source directories, resources and other unmanaged directories.

The python script to run. This file may not exist if this module is only a library.

Map dependencies before resolving them - use only if you know what you are doing. Override this to customize the set of dependencies.

Using this makes it harder to make sense of dependency resolutions and to reproduce those resolutions via the coursier command-line or from other build tools.

A CoursierModule.Resolver to resolve dependencies.

Unlike defaultResolver, this resolver can resolve Mill modules too (obtained via JavaModule.coursierDependencyTask).

The isolated PEX tool environment managed and cached by uv.

Python dependencies to install. Each dependency uses the format accepted by uv pip install or a requirements.txt file.

An executable python interpreter. This interpreter is set up to run in a virtual environment which has been initialized to contain all libraries and tools needed by this module and its dependencies.

Command-line options to pass to the Python Interpreter defined by the user.

Local, non-Mill Python projects to install as dependencies. Each directory should contain standard Python project metadata such as pyproject.toml. Use Task.Sources when overriding this so project contents participate in cache invalidation.

Requirements files to install for this module.

Python dependencies used only as development tools, such as type checkers, linters, and bundlers.

Python version request passed to uv when creating the virtual environment.

If you'd like to use a specific python version, override this task to point to a specific python executable.

Examples:

// use Mill's default modern Python version
def pythonVersion = T{ "3.12" }

// use a specific minor release
def pythonVersion = T{ "3.13" }

// use a specific executable file
def pythonVersion = T{ "/usr/bin/python3" }

The repositories used to resolve dependencies with classpath(). This takes Coursier repository strings as input which are defined here:

• https://github.com/coursier/coursier/blob/main/docs/pages/reference-repositories.md

For example:

• https://repo1.maven.org/maven2 Maven Central which is the most commonly used Maven repository

• file:///Users/alex/test-repo A local repository cache on disk

• file://${ivy.home-${user.home}/.ivy2}/local/[defaultPattern] The local Ivy2 repository where Mill, Scala CLI, or sbt publish to when asked to publish locally

• file://${user.home}/.m2/repository the local Maven repository. Use of this is not recommended for reasons explained in the link above

• https://maven.google.com Google-managed repository that distributes some Android artifacts in particular

A more flexible version of repositories, that allows custom repositories that are not definable by Coursier repository strings. This is a relatively advanced feature, and for most situations overriding repositories should be sufficient

See allRepositories if you need to resolve Mill internal modules.

Customize the coursier resolution process. This is rarely needed to changed, as the default try to provide a highly reproducible resolution process. But sometime, you need more control, e.g. you want to add some OS or JDK specific resolution properties which are sometimes used by Maven and therefore found in dependency artifact metadata. For example, the JavaFX artifacts are known to use OS specific properties. To fix resolution for JavaFX, you could override this task like the following:

   override def resolutionCustomizer = Task.Anon {
     Some( (r: coursier.core.Resolution) =>
       r.withOsInfo(coursier.core.Activation.Os.fromProperties(sys.props.toMap))
     )
   }

Resolution parameters, allowing to customize resolution internals

This rarely needs to be changed. This allows to disable the new way coursier handles BOMs since coursier 2.1.17 (used in Mill since 0.12.3) for example, with:

 def resolutionParams = super.resolutionParams()
   .withEnableDependencyOverrides(Some(false))

Note that versions forced with Dep#forceVersion() take over forced versions manually set in resolutionParams. The former should be favored to force versions in dependency resolution.

The Scala version set via ScalaModule#scalaVersion also takes over any Scala version provided via ResolutionParams#scalaVersionOpt.

The default configuration set in ResolutionParams#defaultConfiguration is ignored when Mill fetches dependencies to be passed to the compiler (equivalent to Maven "compile scope"). In that case, it forces the default configuration to be "compile". On the other hand, when fetching dependencies for runtime (equivalent to Maven "runtime scope"), the value in ResolutionParams#defaultConfiguration is used.

The folders where the resource files for this module live.

Run the main python script of this module.

Run the main python script of this module.

The paths where the source files for this Mill module live.

Standard PythonModules return source directories, while BarePythonModule returns individual files whose import names are based on their paths relative to the workspace root.

Returns a string representation of the object.

The default representation is platform dependent.

Python dependencies of this module and all upstream modules.

The transitive version of localPythonPath: this includes the directories of all upstream modules as well.

Local Python projects of this module and all upstream modules.

Requirements files of this module and all upstream modules.

Direct wheels of this module and all upstream modules.

The isolated ty tool environment managed and cached by uv.

Run a typechecker on this module.

Additional directories to include in the PYTHONPATH directly. These paths are "unmanaged": they'll be included as they are on disk.

Python wheels to install directly. Local wheels should be declared here so their signatures participate in Mill cache invalidation.

URL of the SHA-256 checksum for uvDownloadUrl.

URL of the platform-specific uv archive Mill downloads.

The uv executable used by this module. Mill downloads it once into the shared Coursier archive cache, verifies its SHA-256 checksum, and reuses it across builds.

uv arguments that preserve the priority order declared by indexes.

Arguments passed to uv pip install when preparing the environment.

This is an escape hatch. Prefer overriding the higher-level dependency, local-project, wheel, requirements-file, or index tasks.

A runner for invoking uv with the module environment.

The uv version Mill downloads and uses.