Answers

I exported my conda environment and froze pip, but the new environment won't solve or won't run. Can I just copy the venv folder?

An export is an install list, not an environment. It can name packages no index serves (conda-only builds, packages that came with the operating system, a package installed from a local folder, a torch built inside a container), and a venv holds absolute paths from the machine that made it, so copying it elsewhere breaks it. What works is a list of exact versions plus a check that the list can still be installed on the target before you depend on it.

Why won't my exported environment solve or install on the new machine?

Because some lines in it name things that exist only on the old machine:

• Packages that came with the operating system — when the app ran on the image's own Python instead of a virtual environment, the freeze lists packages like python-apt that no package index has ever published.
• conda-only packages — conda's own parts and builds recorded as file:///croot/… paths that exist on no other machine.
• A package installed from a folder — pip install -e . (the last line of kohya_ss's requirements) is frozen as an ordinary-looking name== line pinned to a version that no index carries.
• Builds made in a container or by a vendor — a torch such as 2.1.0a0+git… exists on no index; a +cu124 build lives only on the vendor's own download server.

And a requirements file without exact versions is worse: it's a question the resolver answers differently each time. See A fresh resolve is a different environment.

Can I just copy the venv folder to another machine?

Not reliably. A venv points at the Python that created it by absolute path, its scripts start with that path, and compiled packages inside it were built for that machine's Python and system. Move it to a different path or a different base image and it breaks in ways that look unrelated. Rebuild it from a version list instead.

So what actually brings an environment back?

1. A list of exact versions that were installed when the thing worked — taken from the working environment, not re-derived later.
2. Built inside a virtual environment, so nothing in the list belongs to the operating system.
3. A check that the list installs on the target before you download 50 GB of models next to it.

How does Renest deal with packages that can't be reinstalled?

When packing, Renest records the exact versions from the environment that worked and reads the list for the dead ends above. It doesn't refuse: the files are still a faithful record of that machine. It warns, naming the packages and the fix for each kind (rebuild in a uv venv and pack again, or pack the local folder as code), takes conda's own installer parts out of the list, and marks the nest as not restorable on another machine, so a hand-off of it can be refused. Vendor builds such as +cu124 get their direct download address recorded instead.

$ renest pack --dir ./run --workflow workflow-api.json --dry-run

When restoring, before any model files download, Renest asks uv whether the recorded list can be installed on this machine. A definite "no solution" stops it there, before the big download. Then the restore installs exactly the recorded list — no new resolution — and checks every file against its recorded checksum. Details in Capture a run and The pre-flight check.

A version list pins versions, not bytes: packages without a recorded fingerprint are fetched by name and version, and a package taken down from its source can't be brought back by any list.

When Renest isn't the answer

• A plain Python project with no GPU builds — a lock file from uv or pip-tools, committed next to your code, is enough.
• The environment never worked in the first place — no list can carry a working state that never existed; Renest packs runs that already worked.
• You need a conda environment rebuilt as conda — Renest rebuilds with uv from package indexes; conda's own lock tools are the right fit there.

Related: What a ComfyUI backup has to include · kohya_ss or LLaMA-Factory on a new GPU