Struct PipSyncArgs 

pub struct PipSyncArgs {

    pub src_file: Vec<PathBuf>,
    pub constraints: Vec<Maybe<PathBuf>>,
    pub build_constraints: Vec<Maybe<PathBuf>>,
    pub extra: Option<Vec<ExtraName>>,
    pub all_extras: bool,
    pub no_all_extras: bool,
    pub group: Vec<PipGroupName>,
    pub installer: InstallerArgs,
    pub refresh: RefreshArgs,
    pub require_hashes: bool,
    pub no_require_hashes: bool,
    pub verify_hashes: bool,
    pub no_verify_hashes: bool,
    pub python: Option<Maybe<String>>,
    pub system: bool,
    pub no_system: bool,
    pub break_system_packages: bool,
    pub no_break_system_packages: bool,
    pub target: Option<PathBuf>,
    pub prefix: Option<PathBuf>,
    pub no_build: bool,
    pub build: bool,
    pub no_binary: Option<Vec<PackageNameSpecifier>>,
    pub only_binary: Option<Vec<PackageNameSpecifier>>,
    pub allow_empty_requirements: bool,
    pub no_allow_empty_requirements: bool,
    pub python_version: Option<PythonVersion>,
    pub python_platform: Option<TargetTriple>,
    pub strict: bool,
    pub no_strict: bool,
    pub dry_run: bool,
    pub torch_backend: Option<TorchMode>,
    pub compat_args: PipSyncCompatArgs,
}

Fields

src_file: Vec<PathBuf>

Include the packages listed in the given files.

The following formats are supported: requirements.txt, .py files with inline metadata, pylock.toml, pyproject.toml, setup.py, and setup.cfg.

If a pyproject.toml, setup.py, or setup.cfg file is provided, uv will extract the requirements for the relevant project.

If - is provided, then requirements will be read from stdin.

constraints: Vec<Maybe<PathBuf>>

Constrain versions using the given requirements files.

Constraints files are requirements.txt-like files that only control the version of a requirement that’s installed. However, including a package in a constraints file will not trigger the installation of that package.

This is equivalent to pip’s --constraint option.

build_constraints: Vec<Maybe<PathBuf>>

Constrain build dependencies using the given requirements files when building source distributions.

Constraints files are requirements.txt-like files that only control the version of a requirement that’s installed. However, including a package in a constraints file will not trigger the installation of that package.

extra: Option<Vec<ExtraName>>

Include optional dependencies from the specified extra name; may be provided more than once.

Only applies to pylock.toml, pyproject.toml, setup.py, and setup.cfg sources.

all_extras: bool

Include all optional dependencies.

Only applies to pylock.toml, pyproject.toml, setup.py, and setup.cfg sources.

no_all_extras: bool

group: Vec<PipGroupName>

Install the specified dependency group from a pylock.toml or pyproject.toml.

If no path is provided, the pylock.toml or pyproject.toml in the working directory is used.

May be provided multiple times.

installer: InstallerArgs

refresh: RefreshArgs

require_hashes: bool

Require a matching hash for each requirement.

By default, uv will verify any available hashes in the requirements file, but will not require that all requirements have an associated hash.

When --require-hashes is enabled, all requirements must include a hash or set of hashes, and all requirements must either be pinned to exact versions (e.g., ==1.0.0), or be specified via direct URL.

Hash-checking mode introduces a number of additional constraints:

• Git dependencies are not supported.
• Editable installations are not supported.
• Local dependencies are not supported, unless they point to a specific wheel (.whl) or source archive (.zip, .tar.gz), as opposed to a directory.

no_require_hashes: bool

verify_hashes: bool

no_verify_hashes: bool

Disable validation of hashes in the requirements file.

By default, uv will verify any available hashes in the requirements file, but will not require that all requirements have an associated hash. To enforce hash validation, use --require-hashes.

python: Option<Maybe<String>>

The Python interpreter into which packages should be installed.

By default, syncing requires a virtual environment. A path to an alternative Python can be provided, but it is only recommended in continuous integration (CI) environments and should be used with caution, as it can modify the system Python installation.

See uv help python for details on Python discovery and supported request formats.

system: bool

Install packages into the system Python environment.

By default, uv installs into the virtual environment in the current working directory or any parent directory. The --system option instructs uv to instead use the first Python found in the system PATH.

WARNING: --system is intended for use in continuous integration (CI) environments and should be used with caution, as it can modify the system Python installation.

no_system: bool

break_system_packages: bool

Allow uv to modify an EXTERNALLY-MANAGED Python installation.

WARNING: --break-system-packages is intended for use in continuous integration (CI) environments, when installing into Python installations that are managed by an external package manager, like apt. It should be used with caution, as such Python installations explicitly recommend against modifications by other package managers (like uv or pip).

no_break_system_packages: bool

target: Option<PathBuf>

Install packages into the specified directory, rather than into the virtual or system Python environment. The packages will be installed at the top-level of the directory.

Unlike other install operations, this command does not require discovery of an existing Python environment and only searches for a Python interpreter to use for package resolution. If a suitable Python interpreter cannot be found, uv will install one. To disable this, add --no-python-downloads.

prefix: Option<PathBuf>

Install packages into lib, bin, and other top-level folders under the specified directory, as if a virtual environment were present at that location.

In general, prefer the use of --python to install into an alternate environment, as scripts and other artifacts installed via --prefix will reference the installing interpreter, rather than any interpreter added to the --prefix directory, rendering them non-portable.

Unlike other install operations, this command does not require discovery of an existing Python environment and only searches for a Python interpreter to use for package resolution. If a suitable Python interpreter cannot be found, uv will install one. To disable this, add --no-python-downloads.

no_build: bool

Don’t build source distributions.

When enabled, resolving will not run arbitrary Python code. The cached wheels of already-built source distributions will be reused, but operations that require building distributions will exit with an error.

Alias for --only-binary :all:.

build: bool

no_binary: Option<Vec<PackageNameSpecifier>>

Don’t install pre-built wheels.

The given packages will be built and installed from source. The resolver will still use pre-built wheels to extract package metadata, if available.

Multiple packages may be provided. Disable binaries for all packages with :all:. Clear previously specified packages with :none:.

only_binary: Option<Vec<PackageNameSpecifier>>

Only use pre-built wheels; don’t build source distributions.

When enabled, resolving will not run code from the given packages. The cached wheels of already-built source distributions will be reused, but operations that require building distributions will exit with an error.

Multiple packages may be provided. Disable binaries for all packages with :all:. Clear previously specified packages with :none:.

allow_empty_requirements: bool

Allow sync of empty requirements, which will clear the environment of all packages.

no_allow_empty_requirements: bool

python_version: Option<PythonVersion>

The minimum Python version that should be supported by the requirements (e.g., 3.7 or 3.7.9).

If a patch version is omitted, the minimum patch version is assumed. For example, 3.7 is mapped to 3.7.0.

python_platform: Option<TargetTriple>

The platform for which requirements should be installed.

Represented as a “target triple”, a string that describes the target platform in terms of its CPU, vendor, and operating system name, like x86_64-unknown-linux-gnu or aarch64-apple-darwin.

When targeting macOS (Darwin), the default minimum version is 13.0. Use MACOSX_DEPLOYMENT_TARGET to specify a different minimum version, e.g., 14.0.

When targeting iOS, the default minimum version is 13.0. Use IPHONEOS_DEPLOYMENT_TARGET to specify a different minimum version, e.g., 14.0.

When targeting Android, the default minimum Android API level is 24. Use ANDROID_API_LEVEL to specify a different minimum version, e.g., 26.

WARNING: When specified, uv will select wheels that are compatible with the target platform; as a result, the installed distributions may not be compatible with the current platform. Conversely, any distributions that are built from source may be incompatible with the target platform, as they will be built for the current platform. The --python-platform option is intended for advanced use cases.

strict: bool

Validate the Python environment after completing the installation, to detect packages with missing dependencies or other issues.

no_strict: bool

dry_run: bool

Perform a dry run, i.e., don’t actually install anything but resolve the dependencies and print the resulting plan.

torch_backend: Option<TorchMode>

The backend to use when fetching packages in the PyTorch ecosystem (e.g., cpu, cu126, or auto).

When set, uv will ignore the configured index URLs for packages in the PyTorch ecosystem, and will instead use the defined backend.

For example, when set to cpu, uv will use the CPU-only PyTorch index; when set to cu126, uv will use the PyTorch index for CUDA 12.6.

The auto mode will attempt to detect the appropriate PyTorch index based on the currently installed CUDA drivers.

This option is in preview and may change in any future release.

compat_args: PipSyncCompatArgs

Trait Implementations

impl Args for PipSyncArgs

fn group_id() -> Option<Id>

Report the ArgGroup::id for this set of arguments

fn augment_args<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate Self via FromArgMatches::from_arg_matches_mut

fn augment_args_for_update<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate self via FromArgMatches::update_from_arg_matches_mut

impl FromArgMatches for PipSyncArgs

fn from_arg_matches(__clap_arg_matches: &ArgMatches) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn from_arg_matches_mut( __clap_arg_matches: &mut ArgMatches, ) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn update_from_arg_matches( &mut self, __clap_arg_matches: &ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.

fn update_from_arg_matches_mut( &mut self, __clap_arg_matches: &mut ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.