-
-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wheels for markupsafe #45
Comments
@pallets you should separate out the binary speedups from the main source universal wheel |
There's not much point in universal wheels beyond a minor size reduction and a green bar on that site. In this case it would also give a false sense of what's happening. I am working on figuring this out, but creating a comprehensive set of platform wheels is not well documented, and is even harder when I only have access to Linux. |
@davidism the speedups are optional, so I'd argue it should be in an extras_require value, e.g. |
That's not the plan. Other libraries like SQLAlchemy bundle their speedups as well. The speedups are optional already, if they can't compile the pure Python version is used. |
@davidism Twisted plan on using this approach for wheels: https://twistedmatrix.com/trac/ticket/7945 There are other advantages: You'd only need to rebuild the wheels for speedups changes, which presumably happen less often than the rest of the package. |
SQLAlchemy is anti async/await and wheel so I don't think it's a good idea to follow their approach. |
Why produce a universal wheel at all? That's not more useful than the current distribution formats for this project. If you are going to distribute wheels, then people are going to expect those to include the compiled C speed-ups. That's the real strength of wheels; to distribute pre-built binaries. |
We need Linux, Mac, and Windows; 32 and 64 bit; 2.6, 2.7, 3.3, 3.4, 3.5, and 3.6 builds. Travis can handle Linux (manylinux) and Mac; Appveyor does Windows. If anyone has experience setting these up contributions are welcome. Otherwise I'll keep working away at it when I have time. |
@mjpieters @davidism wheels are much faster to install (even than pure python sdists), and when you're installing hundreds of packages it makes a big difference. |
Also the markupsafe C module is only an optional speedup, so would work very well as a separate module. |
It's a massive pain to set up these things. If someone wants to do it, you can use getsentry/libsourcemap and getsentry/symsynd as a point of reference. //EDIT: I want to clarify one thing: there will not be wheels without the speedups because then nobody would be able to install the speedups any more. |
@mitsuhiko what makes you think that nobody would be able to install the speedups if they were a separate package? |
The entire point of markupsafe is the speedups. The only reason we have a fallback is because of user friendliness. Nobody should ever use markupsafe without the speedups. Feature flags barely work, definitely do not work with wheels and a |
@mitsuhiko I was actually thinking that you'd have the speedups in |
Since this hypothetical Also this will shave off basically no time since pip caches wheels locally anyways. |
Yeah it would not be a great improvement but it means that the pure python would not go stale when a new binary was published |
I just don't get what exactly this is supposed to solve. MarkupSafe installs very quickly if there is no c compiler on the system. How much time are we talking about here? |
@graingert not sure how that is in any way relevant to the installation speed of markupsafe. |
|
not sure if I linked to the correct comment, but it should be one benchmarking a pure-python wheel |
So from what I can tell downloading + installing markupsafe without compiling here takes 1.1 seconds with compiling 2 seconds and downloading and installing markupsafe from a wheel takes 0.8 seconds. That does not seem at all important in the grand scheme of things. Even more so now that pip caches wheels locally so once you have installed markupsafe once it will just reused the wheel from the cache. |
I can't reproduce the 1.1sec vs 0.8 sec even. They are more or less the same when run multiple times. That also makes sense because there is barely any sourcecode in markupsafe and few files. |
You said markupsafe installs quickly now, but you missed one fact for current master - it installs from github, instead of PyPi. So, while existence of wheels is a question, PyPi packages has big advantages after git:
So, although there is no wheels, I think we still need PyPi release. |
I pushed up 1.0. |
Thanks @mitsuhiko ! |
Fwiw the performance improvement is not the only benefit, distributing as a wheel also:
If it helps, there's now a demo project for using manylinux1: |
The manylinux example has been around for a while, and is great. The issue is figuring out the huge matrix of Mac and Windows builds, which have very sparse documentation as far as I can find. #45 (comment) I don't want to release a wheel just to satisfy a green check on a website, I want to release a good set of wheels to actually be useful. Paul Kehrer has a good talk about the permutations to keep in mind: https://youtu.be/-j4lolWgD6Q?t=16m33s. #65 adds support for building Windows wheels, but I have not had time to review it. If anyone is familiar and wants to help review, that would be great. I would also appreciate any help getting Travis set up to produce Mac builds (and manylinux too). |
I agree it would be good to cover all platforms, however there's no disadvantage to rolling out wheels builds incrementally for certain platforms first - especially given that certain combinations (eg linux) will cover a significant proportion of downloads :-) |
I'm not very concerned with Linux since the extension requires nothing besides a compiler and the Python headers. Obviously it would be good to have, but I'm not going to close this issue just with that. |
@davidism if this can help I have CI repos I use specifically to build wheel on Linux, macOS and Windows at https://github.com/pombreda/thirdparty and https://github.com/pombreda/thirdparty-manylinux/ |
@edmorley FWIW if this can help, you can use a check or tarbal and run @davidism unrelated but the setuptools |
From what I remember, it's gone back and forth a few times. I think the alternative is |
Thanks to @dougthor42 #65 we now have Windows wheels for 2.6-3.6 32/64. I will upload them with the next release. |
Could someone please upload a wheel for MarkupSafe 1.0? |
thank you! |
PyPI has wheels for MarkupSafe 1.1.0. |
Do you consider providing Python wheels for markupsafe? cf. http://pythonwheels.com/
The text was updated successfully, but these errors were encountered: