Ways to speed up Wagtail installs

Is your proposal related to a problem?

I just came out of a workshop where we had participant install Wagtail on Windows, and we noticed quite slow install times, up to 5-10 minutes for a participant. I suppose an element of this might just be slower machines, and @tomdyson let me know on Slack that it’s also important to use an up-to-date version of pip as older versions might not be able to use wheels. I wonder if there are other things we could do to speed up the install though, even if only by a few seconds.

Describe the solution you’d like

Inspecting a Wagtail install (on macOS),

Wheels

It looks like three of Wagtail’s dependencies don’t have prepublished wheels. Should we consider making PRs?

Building wheel for l18n (setup.py) ... done
Building wheel for django-treebeard (setup.py) ... done
Building wheel for draftjs-exporter (setup.py) ... done

For draftjs-exporter – I can easily publish as a wheel, not sure why it’s not set up yet (https://github.com/springload/draftjs_exporter/issues/132).

static_src

There is a line in our MANIFEST.in excluding a static_src folder – however it’s using a path that no longer exists since wagtail 2.0. Should we have all static_src folders there?

https://github.com/wagtail/wagtail/blob/e10a9f26e7c944fd3a037a0459d371ab122ff96d/MANIFEST.in#L3

global-exclude static_src

tests

We could also probably not publish our tests with Wagtail, hopefully just with:

global-exclude tests
global-exclude tests.py

Source maps

Wagtail only ships three source maps, but together those files account for about 4MB. I think I liked the idea of shipping these with Wagtail so users could report on JS errors that were intelligible, but in practice I haven’t seen this done that much since we started shipping those files.

2.1M	admin/static/wagtailadmin/js/draftail.js.map
1.1M	admin/static/wagtailadmin/js/vendor.js.map
440K	admin/static/wagtailadmin/js/wagtailadmin.js.map

To exclude these,

global-exclude *.map

Other files

Here are other patterns we should be able to exclude, resulting in small savings:

global-exclude .gitignore
# Single file but is quite big and does nothing at runtime.
global exclude wagtail-icomoon.json

(Describe your proposed solution here.)

---

Here is the change with all those modifications done:

# Before
29MB, 1742 directories, 2803 files
# After
19MB, 1647 directories, 2356 files

Not night-and-day, but worth considering. Is there anything I’ve missed? Anything from the list above that seems like a bad idea?

[PaarthAgarwal]

I’d like to work on this issue

[gasman]

There’s no licence problem with handsontable - that was a miscommunication. The non-OSS-compatible licence was introduced in version 7, so as long as we stick with 6.x I believe we’re fine.