Part of the motivation for using wheels in our case was to allow for pulling in later versions of certain python packages as part of the dependency resolution process when installing or updating the package. Using RPM while attempting to get the updated dependencies would mean having to repackage every single dependency (direct and indirect) from pypi as RPMs and upload them to our yum repo so that yum would be able to handle dependency resolution.
> I don't think anyone advertised them as such. They replace eggs or installing from source .py files,
The setup method from setuptools does have the necessary features for handling system-level files and the bdist_rpm command leveraged that when building RPMs. It just seems that if this was a bug rather than a feature, then it should have been noted when transitioning from egg based distributions to wheels. Nothing in the documentation for eggs or wheels states that they don't support deploying system files in absolute file paths.
The fact that doing something like:
pip install git+ssh://[email protected]/org/[email protected]
and
pip install project==1.2.3
have different results for where files listed in the data_files named parameter of the setup end up on the file system suggest that the lack of absolute path support when installing wheels is a bug rather than an intentional change.
I don't think the Wheel specification was intended to replace application distribution. It is aimed at the distribution of individual Python libraries.
Wheel is an unpack-into-any-prefix (and stays in that prefix) binary distribution format.
Libs are for the dev: you want the source code, you want to manage versions, you want it to integrate with your dev env, you want a well delimited scope, a way to install it using your usual setup (pip/poetry/etc) and to isolate it from project to project.
The established behavior of python setuptools when creating an RPM spec file via the bdist_rpm command was to create a spec file that would invoke the build command in the %build section and the install command in the %install section. The install command would place those files in the absolute paths specified in the data_files named parameter.
It has worked this way even back when distutils.core, the predecessor of setuptools, was used.
As for whether it's desirable, if you're missing the config file, init script, and other things necessary for an application to work, then you essentially have an incomplete installation and will have to copy those files from other sources and update them yourself via config management before you're able to run it.
> I guess I'm just asking, aren't these two separate problems (config management and Python packaging)?
In my view, config management should update a config file that's already there and also restart the service as needed (either when the package is updated, the config file is updated, or both). It shouldn't be responsible for placing the config file and init script itself.
For example, if I install an application like redis or rabbitmq-server, the package manager will place the included sample config file in the correct directory (e.g., /etc). I can further modify that file as necessary before starting the service. It will also include the scripts necessary to start the service as a daemon. Config management could be used to update the config file for environment specific concerns, but it doesn't need to essentially duplicate what the package manager has already done (create the directories, set permissions, place the file, etc). Python applications, regardless of how they're packaged, shouldn't really be different in this regard.
You create a RPM _from_ a Python package. The RPM (and associated software) writes init files to the correct place. This bears no relevance on wheels, which absolutely should not be filled with district-specific knowledge about init scripts and should definitely not write to random hard-coded paths.
Where is that documented? The fact that setuptools and distutils.core supported building RPM packages from a setup.py file indicates that python intended to support application distribution. Why remove that capability when moving to wheels?
> This bears no relevance on wheels, which absolutely should not be filled with district-specific knowledge about init scripts and should definitely not write to random hard-coded paths.
One thing I noted while figuring out this issue is that running:
pip install git+ssh://[email protected]/org/[email protected]
versus
pip install project==1.2.3
where project was packaged as a wheel on pypi had different results with regards to where files referenced by the data_files named parameter in the setup call were placed on the file system. Given that, was the change intentional, or is it a bug with how wheels handle package installation?
The other issue is that there's no equivalent of the %(config) RPM spec directive to prevent the config file from being overwritten if it already exists on the file system.
So, for libraries, wheels are a good cross-platform packaging solution, but not so much for applications that require configuration files and init scripts.