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 <destination path> -> <source path>. Where <destination path> is relative to some build directory, where you'll also find src and pyproject.toml.

Run twine check to catch some common packaging errors.

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 by setting any environment variables understood by twine, prefixed with MILL_. For example, to change the repository URL:

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

All artifacts that should be published.

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 setuptools as the build backend, and 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 the build python command, although this is an implementation detail). You can include additional files in this directory via the buildFiles task.

Any python dependencies for development tools you want to add to this module.

These dependencies are similar to pythonDeps, but will not be required to install this module, only to work on it. For example, type checkers, linters, and bundlers should be declared here.

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#coursierDependency).

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 single PEX executable(bundle.pex).

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))
    )
 }

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

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.

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 target itself, or can refer to files generated from other targets

Python interpreter found on the host system. This will be used to create a new virtual environment, which will be used by all tasks in this module.

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

Examples:

// use whatever python version is installed on the host system (default)
def hostPythonCommand = T{ "python3" }

// use a specific minor release
def hostPythonCommand = T{ "python3.12" }

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

Base URLs of the Python Package Indexes to search for packages. Defaults to https://pypi.org/simple.

These should point to repositories compliant with PEP 503 (the simple repository API) or local directories laid out in the same format.

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. Override this to customize the set of dependencies.

A CoursierModule.Resolver to resolve dependencies.

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

Arguments to be passed to pip install when preparing the environment.

This task is called by pythonExe. It serves as an escape hatch, should you need to override it for some reason. Normally, you should not need to edit this task directly. Instead, prefer editing the other tasks of this module which influence how the arguments are created.

Any python dependencies you want to add to this module. The format of each dependency should be the same as used with pip install, or as you would find in a requirements.txt file. E.g. def pythonDeps = Seq("numpy==2.1.3").

Dependencies declared here will also be required when installing this module.

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.

Python dependencies declared in requirements.txt files. This is similar to pythonDeps, but reads dependencies from a text file, allowing you to reuse requirements files from existing projects.

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 folders where the source files for this mill module live.

Python modules will be defined relative to these directories.

Returns a string representation of the object.

The default representation is platform dependent.

Python dependencies of this module, and all other modules that this module depends on, recursively.

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

requirements.txt of this module, and all other modules that this module depends on, recursively.

Any python wheels to install directly, for this module and all upstream modules, recursively.

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.

Any python wheels to install directly.

Note: you can also include wheels by using direct references in pythonRequirementFiles, for example "pip @ file:///localbuilds/pip-1.3.1-py33-none-any.whl". However, if you do that then changes to these files won't get picked up and you are on the hook for cache invalidation. Therefore, if you have any wheels that you wish to install directly, it is recommended to add them here.