#19252 closed Bug (fixed)
Install from wheel package
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Packaging | Version: | dev |
Severity: | Release blocker | Keywords: | |
Cc: | Florian Apolloner | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
On Mac OS, pip wheel
builds a Django wheel which installs cleanly. On Linux, it builds a wheel which (correctly) marks data files as such, and they get installed outside the django
package. This doesn't happen on Mac OS since setup.py
tricks distutils into handling data files as purelib files.
This little patch extends the setup.py
hack to kick in when building wheels regardless of platform: https://gist.github.com/4018017. The osx_install_data
should probably be renamed though.
Change History (15)
comment:1 by , 12 years ago
Severity: | Normal → Release blocker |
---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Version: | 1.4 → master |
comment:4 by , 12 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
The wheel format isn't accepted yet (http://www.python.org/dev/peps/pep-0427/) and there is currently no such feature in pip. Closing as invalid as it's basically not a problem we should try to fix.
comment:5 by , 12 years ago
This bug is exactly the same thing that happens, and is currently compensated for, when building bdist_wininst installers. This should be a hint that data files are a problem.
Why not fix it for everyone by disusing the data files feature of distutils, regardless of sys.argv?
comment:6 by , 12 years ago
Resolution: | invalid |
---|---|
Severity: | Release blocker → Normal |
Status: | closed → new |
The wheel PEP is now accepted, and pip will soon have support AFAIK.
Regardless, comment 5 is correct that we jump through way too many hoops in our setup.py in order to try to trick distutils into handling data_files
as if they were package_data
, and that is the root cause of this bug. Instead we should just use package_data
and solve the problem properly.
I don't believe this is a 1.5 release blocker, though, so re-setting the severity to Normal.
comment:7 by , 12 years ago
Severity: | Normal → Release blocker |
---|
I'd like to start distributing Django as a wheel for 1.6, so I'm re-marking this as a release blocker. As we get closer to 1.6 we can revisit whether the ecosystem is "ready" and perhaps punt, but making this a blocker now means we won't just forget.
comment:8 by , 12 years ago
Component: | Core (Other) → Packaging |
---|
comment:9 by , 12 years ago
FWIW our resolution of data-files is borked currently: https://github.com/django/django/blob/master/setup.py#L72
This results in: django/conf/project_template beeing data and django/conf/project_template/project_name beeing a package. As such a wheel install currently puts manage.py somehwere else and startproject doesn't collect all files…
So the whole setup.py needs a bit more rework.
comment:10 by , 12 years ago
Cc: | added |
---|
comment:11 by , 12 years ago
comment:12 by , 12 years ago
Building wheels is possible via:
pip wheel .
(Assuming pip 1.4 and installed distribute and wheel). python setup.py bdist_wheel doesn't work since we don't use setuptools in setup.py, but that's fine.
comment:13 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Perhaps those files should always be purelib files?