| 8 Apr 2019 |
 naomi | The documentation says that this is to ensure that we have the appropriate version of Django, but is that not ensured by the requirements in setup.py? Is it that we have a stronger opinion about versions in requirements.txt than in setup.py? | 15:42:26 |
 mattwestcott | Yes, it is still necessary to install them first - they're system-level native libraries, so they can't be installed automatically through pip as dependencies of either Wagtail or Pillow. | 15:45:03 |
| mattwestcott | It is a bit of an edge case... from what I remember, that came about when we started to support Django 2.0 on an experimental basis, but the project template was still written for Django 1.x | 15:48:50 |
| mattwestcott | so, in that particular window of time, Wagtail's own dependencies allowed Django 2.0, but projects created with wagtail start didn't. | 15:49:39 |
| naomi | Got it. And you install them with homebrew or whatever, which is why it’s annoying to list the options for each platform? I ask in large part because I’m finding Pillow’s documentation about it isn’t awfully readable. | 15:50:12 |
 coenvanderkamp | So requirements.txt are the pinnings for the project itself. Pinning packages makes sure you can roll out your project on various environments. | 15:50:12 |
| coenvanderkamp | (edited) ... out your project ... => ... out identical project ... | 15:50:35 |
| naomi | So the real question here is: can we remove it from the installation instructions because it’s not actually needed at the moment, or should we keep it because it’s good to have it exposed as part of the process of installing projects and because we could run into that edge case in the future? (I lean toward removing, personally.) | 15:52:17 |
| mattwestcott | Yep - in particular, it's likely to be different for every different flavour of Linux | 15:52:27 |
| coenvanderkamp | I would change this is to ensure that we have the appropriate version of Django into When you install a new python package, you should add it to requirements.txt and pin the version. | 15:53:13 |
| naomi | That sounds appropriate to me if I can find the right place to put it 🙂 | 15:53:55 |
| naomi | :+1::skin-tone-2: thank you! | 15:54:04 |
| coenvanderkamp | The js equivalent is package.json | 15:54:36 |
| mattwestcott | I'd prefer to keep that step in place - if the edge case does come up again, then the hassle of dealing with it will greatly outweigh the inconvenience of running one extra command. | 15:55:39 |
| coenvanderkamp | This is the default, we should keep it. FYI some docs https://pip.pypa.io/en/stable/reference/pip_freeze/ | 15:57:22 |
| coenvanderkamp | pip also supports installing from “requirements files”, which provide an easy way to specify a whole environment to be installed. | 15:58:36 |
| mattwestcott | Please let's not encourage people to use pip freeze, unless we're explaining how to use it alongside a hand-written requirements file... | 15:59:47 |
| mattwestcott | (relying on pip freeze on its own means that you end up with one big file full of packages you don't recognise, and super-specific version numbers, with no way to know which ones are safe to upgrade) | 16:00:42 |
| coenvanderkamp | I don't want to encourage it. Just wanted to provide Naomi with some context. The downside of freeze is that it dumps all pinnings of the complete dependency tree. You likely want only top level packages and some prefer to restict pinning within a range eg Wagtail<=3 So you only get 2.x.x. | 16:04:09 |
| naomi | i’m familiar with pip requirements etc 🙂 just wasn’t sure why we needed to say twice which version of django we wanted | 16:04:52 |
| naomi | (edited) ... sure why we needed ... => ... sure whether we really needed ... | 16:06:17 |
| mattwestcott | More broadly, there is a distinction between "Wagtail's dependencies" and "a Wagtail project's dependencies", which may become more relevant in future if - for example - we make Whoosh the default search engine for new projects | 16:11:01 |
| mattwestcott | (at which point whoosh will be part of the dependencies of a new wagtail start project, but won't be a dependency of Wagtail itself) | 16:11:43 |
| naomi | thank you both 🙂 this all helps inform how i’m going to edit the sentence that says why we have that line | 16:12:36 |
| naomi | I ended up making just a small change to it: https://github.com/wagtail/wagtail/pull/5210/files#diff-c9ff385ec9bf22ea0114be2b2cfa6e33R87 | 22:31:19 |
| mattwestcott | The long awaited release candidate of Wagtail 2.5 is now out 🙂 https://pypi.org/project/wagtail/#history | 23:43:26 |
| mattwestcott | release notes: https://docs.wagtail.io/en/latest/releases/2.5.html | 23:43:47 |
| 9 Apr 2019 |
|  andreykus set a profile picture. | 07:24:16 |
| andreykus | Thanks! | 07:24:16 |
| coenvanderkamp | The instructions improved greatly. I added some comments. Feel free to veto them. Just suggestions. | 08:08:42 |
