It should be possible to create a Wagon file for requirement files without source

[andythomas501]

I have a requirements file for a bunch of packages I want to install on some servers. I want to use Wagon to easily package and install them. However, Wagon forces me to select a "source" package. I can arbitrarily select one of the packages I want to install, specify it as "soruce", and remove it from the requirement files (to avoid a duplication error), but I think it would be best if I could just use Wagon to "archive" a list of unrelated packages.

[nir0s]

So, you'd expect to send a requirements file as an "argument" to wagon, it will download all wheels and put them in a single wgn. Is this right?

How should the metadata reflect this from your POV?

[andythomas501]

I don't really mind what's in the metadata.

[nir0s]

Note that we're working on a redo for Wagon and will try to include this feature in the new version.

[nir0s]

Sorry, but it seems we'll only be able to promote this with version v1.0.0 which has an unknown release date.

[ncoghlan]

I have a similar need when generating a wagon archive to include in a larger installation bundle, but came up with a workaround I'm happy with, which is to create a minimal dev/setup.py file, then run:

wagon create -r locked-requirements.txt -f -t tar.gz dev

The minimal setup.py file is just:

"""Python pseudo-package for install bundle generation"""

from distutils.core import setup

setup(
    name="my_company_python_deploy_bundle",
    version="1",
    description="Pseudo-package for Python install bundle generation",
    author="<My company> <My project> development team",
    packages=[],
)

This is enough to give wagon the info it needs to generate the bundle filename (i.e. my_company_python_deploy_bundle-1-...) without needing to define a full publishable Python package.

[ncoghlan]

After further experimentation, I discovered a problematic bug when SOURCE is given as a relative local directory: wagon still tries to go and grab a project of the same name from PyPI.

So in my dev example above, I was ending up with a copy of https://pypi.org/project/dev/ in the created wagon archive.

Switching the local relative to source directory to install instead results in an error.

To make sure wagon doesn't try to check PyPI there needs to be a directory separator in the local path reference:

wagon create -r locked-requirements.txt -f -t tar.gz ./install

[nir0s]

This is actually by design, much like with pip, you should be able to provide just a "name", which will be looked up in PyPi, and a local path. Would you have expected something else?

[ncoghlan]

I'm also interested in app deployment and "standard development environment" type use cases, where wagon is being used to define a managed environment used for application deployment. My specific use case is setting up a shared Python env in an embedded Linux deployment where we have multiple standalone scripts that are rolled out as part of a mostly self-installing firmware update tarball rather than as a Python package. We'll also see a similar situation if folks want to create a wagon from a pipenv-managed application.

The setup.py pseudo-package approach already works (thank you!), so I don't think there's any urgent need for enhancements here, but I do think the UX would be clearer if there was an option to specify the required metadata from the command line (either directly or by specifying a static config file), rather than specifying it indirectly via an executable setup.py script.