4 ms·

Wheels don't, and shouldn't, replace RPM or deb packages, and I don't think anyone advertised them as such. They replace eggs or installing from source .py file

Wheels don't, and shouldn't, replace RPM or deb packages, and I don't think anyone advertised them as such. They replace eggs or installing from source .py files, you should still build RPMs or debs on top of that if you want to do any system-level stuff like set up systemd services, config files in /etc and so on.

u801e 6y ago
> Wheels don't, and shouldn't, replace RPM or deb packages 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://git@github.com/org/project.git@1.2.3 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.
- raziel2p 6y ago
  That makes sense. What I did in the past was include wheels of the project itself and all dependencies (pip download) in the RPM/deb, then create the virtualenv and install dependencies as a post-install script. You could upgrade dependencies by calling pip install -U from the virtualenv, however any time you installed the RPM/deb it would "reset" to the packaged version (though there should be ways to prevent that, e.g. tell pip to never downgrade packages).

u801e 6y ago

> Wheels don't, and shouldn't, replace RPM or deb packages 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://git@github.com/org/project.git@1.2.3 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.

raziel2p 6y ago
That makes sense. What I did in the past was include wheels of the project itself and all dependencies (pip download) in the RPM/deb, then create the virtualenv and install dependencies as a post-install script. You could upgrade dependencies by calling pip install -U from the virtualenv, however any time you installed the RPM/deb it would "reset" to the packaged version (though there should be ways to prevent that, e.g. tell pip to never downgrade packages).