Portable virtual environment or bundling/unbundling for offline systems

[SealedServant]

Is your feature/enhancement proposal related to a problem? Please describe.

I have a use case where the project directory (including .venv inside the project) must be transferred to an offline computer, including all the site-packages, since they cannot be downloaded in the offline environment.

When the project folder is moved to the other computer, the .venv activation scripts break because they reference hardcoded paths from the other computer (on Windows this is %UserProfile%). When I tried to hand-edit the activation script paths I still could not get the venv to work (perhaps a problem with symlinks). The problem can be worked around if the project is initialized in a more universal directory such as the C: drive, but this is not a solution in my case because the folder actually needs to live on a different drive such as D: which is not available on my development computer.

I looked up solutions for this venv problem and the consensus is that venvs are not portable, but I believe that there is no good reason for this limitation and that this could be an excellent problem for the package manager to solve.

Describe the solution you'd like

Option 1: pdm install --source

I found the plugin https://github.com/pdm-project/pdm-download, but the documentation does not explain how this is supposed to work with pdm install. pdm download has an option -d/--dest, so I believe pdm install should have a corresponding -s/--source option to specify a local directory containing the packages (for offline systems that do not have access to a pypi repository). The implicit/default behavior of pdm download is pdm download --dest ./packages, so I believe the default behavior of pdm install should mirror this and first search for a local package directory (i.e. implicitly perform pdm install --source ./packages) followed by the traditional pdm.source search order.

Option 2: pdm bundle / pdm unbundle

Another option is the proposed pdm bundle and pdm unbundle set of commands to make the above behaviors more explicit. pdm bundle could delete the .venv folder, download the packages in the lockfile to a folder in the project root called .pdm-bundle, and archive/zip the project folder. pdm unbundle could unarchive/unzip the project folder, recreate the .venv folder, and install the packages from .pdm-bundle and delete the .pdm-bundle folder. Added checksum verifications would be a bonus to verify data integrity. The archival extension could be a special token such as .pdm, .bundle, or .pdmbundle so that pdm unbundle can identify bundles without needed to specify -p/--project option.

The archival step may not be necessary, but it would be convenient for users who usually perform this step when transferring files to other systems. There could also be a capability to batch or recursively bundle/unbundle all projects in a directory.

Option 3

Yet another solution is to give pdm the ability to implicitly recreate/update/fix a detected broken .venv while preserving the downloaded site-packages. This may be more complicated than the previous approaches which can just recreate the .venv.

Other Options

Open to other suggestions from the community!

By the way, this is a stellar package manager and and it makes my job delightful. Thank you for all the hard work that has gone into making it!