-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
836 lines (787 loc) · 33.4 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<!-- Presentation metadata -->
<title>Can packaging improve Django deployments?</title>
<meta name="description" content="How can packaging Django projects make deployments easier, faster and more reliable?">
<meta name="author" content="Markus Zapke-Gründemann">
<!-- reveal.js CSS -->
<link rel="stylesheet" href="css/reveal.css">
<!-- The id attribute must be defined for the reveal.js-menu themes panel -->
<link rel="stylesheet" href="css/theme/night.css" id="theme">
<!-- Devicons CSS -->
<link rel="stylesheet" href="css/devicons.min.css">
<!-- Font Awesome CSS -->
<link rel="stylesheet" href="css/fa-solid.css">
<link rel="stylesheet" href="css/fa-regular.css">
<link rel="stylesheet" href="css/fa-brands.css">
<link rel="stylesheet" href="css/fontawesome.css">
<!-- Custom CSS -->
<link rel="stylesheet" href="css/custom.css">
<!-- Theme used for syntax highlighting of code -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
</head>
<body>
<div class="reveal">
<div class="slides">
<section data-menu-title="Start">
<h2>Can packaging improve Django deployments?</h2>
<p>DjangoCon Europe 2018</p>
<p>Markus Zapke-Gründemann</p>
<aside class="notes" data-markdown>
<textarea data-template>
Hello, my name is Markus.
I'm very exited to give this talk here at DjangoCon Europe!
I also want to thank the team for doing such a great job with organizing this conference.
Just a brief note before I start: My slides are available online, so you don't have to take notes of everything shown. I'll show the URL at the end of my talk.
</textarea>
</aside>
</section>
<section>
<h2>About me</h2>
<ul>
<p class="fragment">Started creating websites at the of end the 90s</p>
<p class="fragment">Open Source Software Developer</p>
<p class="fragment"><a href="https://lpug.github.io/">Leipzig Python User Group</a> member</p>
<p class="fragment"><a hef="https://www.django-verein.de/">German Django Association</a> founding member</p>
<p class="fragment">Active <a href="https://djangogirls.org/">Django Girls</a> supporter</p>
<p class="fragment"><a href"https://codefor.de/leipzig/">Open Knowledge Lab Leipzig</a> founding member</p>
<p class="fragment">CTO at <a href="http://www.picturepipe.com/">PicturePipe</a></p></p>
</ul>
<aside class="notes" data-markdown>
<textarea data-template>
A few words about me.
* I started creating websites at the end of the 90s because I was fascinated by the new communication possibilities the Internet provided then. I started with Perl, moved to PHP and JavaScript and finally discovered Python.
* Because I never had the opportunity to visit a university I learned everything I know from Open Source. This is one of the main reasons why I am participating in Open Source: To give something back and grow the community.
* I'm a member of the Leipzig Python User Group. They helped me a lot with this talk by giving me the opportunity to do a preview at one of the meetings.
* I am a founding member of the German Django Association, which was founded to organize the first DjangoCon Europe community edition in Berlin in 2010.
* I support Django Girls as a contributor and mentor.
* I also founded the Open Knowledge Lab Leipzig. It's part of Code for Germany, which is inspired by Code for America.
* And I'm CTO at PicturePipe, a company offering services around video submission, encoding and streaming.
</textarea>
</aside>
</section>
<section data-menu-title="Abstract">
<h2>
How can<br>
packaging<br>
Django projects<br>
make deployments<br>
easier, faster<br>
and more reliable?
</h2>
<aside class="notes" data-markdown>
<textarea data-template>
How can packaging Django projects make deployments easier, faster and more reliable?
This is the question I want to discuss today in my talk.
There three things that I have to explain before I start:
1. This talk is not about publishing a Django project to the Python Packaging Index.
2. I'm not a Python packaging expert.
3. These are my personal experiences and views.
</textarea>
</aside>
</section>
<section>
<h2>Key topics</h2>
<ol>
<li class="fragment">The quest</li>
<li class="fragment">Packaging a Django project</li>
<li class="fragment">Installing a packaged Django project</li>
<li class="fragment">Packaging tools comparison</li>
<li class="fragment">Summary</li>
</ol>
<aside class="notes" data-markdown>
<textarea data-template>
Here are the key topics of my talk, so you get a rough idea what I'm going to talk about.
</textarea>
</aside>
</section>
<section data-menu-title="The quest">
<h2 class="fragment" data-fragment-index="2">
My quest for<br>
reproducible<br>
and deterministic<br>
deployments
</h2>
<aside class="notes" data-markdown>
<textarea data-template>
I want to start with a short story about my first Python project.
* I worked on the project back in 2007.
* It was a phone book built with a web application construction kit called Nevow.
* The data was read from directory server using LDAP.
* And it was deployed as a service on a Windows server.
* The application and it's dependencies were bundled together into a single installer.
* The installer did also configure the application server to run behind an Internet Information Server reverse proxy.
This was such much better than the deployment experiences I had before, which were just copying the code via FTP to some remote directory.
And so my quest for reproducible and deterministic deployments begun.
</textarea>
</aside>
</section>
<section>
<section data-menu-title="Packaging a Django project">
<h2>Packaging<br>a Django project</h2>
<aside class="notes" data-markdown>
<textarea data-template>
So let's have a look how a Django projects looks like that has been modified to be packaged.
</textarea>
</aside>
</section>
<section>
<h2>Project structure I</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
myproject
├── manage.py
├── MANIFEST.in # NEW
├── myproject
│ ├── __init__.py
│ ├── apps # NEW
│ │ ├── __init__.py
│ │ └── myapp
│ │ ├── __init__.py
│ │ ├── apps.py
│ │ └── ...
│ └── config # NEW
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── setup.cfg # NEW
└── setup.py # NEW
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
This is the structure of a Django project that can be packaged using setuptools.
Important changes:
* There are three new files: `MANIFEST.in`, `setup.cfg` and `setup.py`
* Apps have been moved into a new created `apps` directory.
* All configuration files have been moved into the new `config` directory.
* Several have been updated like `manage.py`, `settings.py`, `urls.py` and `wsgi.py`.
Let's have a look at some of them.
</textarea>
</aside>
</section>
<section>
<h2>manage.py</h2>
<pre>
<code data-trim data-noescape class="stretch wide python">
1 │ #!/usr/bin/env python
2 │ import os
3 │ import sys
4 │
5 │ if __name__ == "__main__":
6 │ os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.config.settings")
7 │ try:
8 │ from django.core.management import execute_from_command_line
9 │ except ImportError as exc:
10 │ raise ImportError(
11 │ "Couldn't import Django. Are you sure it's installed and "
12 │ "available on your PYTHONPATH environment variable? Did you "
13 │ "forget to activate a virtual environment?"
14 │ ) from exc
15 │ execute_from_command_line(sys.argv)
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
The only change in `manage.py` is in line six where the namespace of the settings module has been updated to use `myproject.config`.
`wsgi.py` has been updated accordingly.
</textarea>
</aside>
</section>
<section>
<h2>settings.py I</h2>
<pre>
<code data-trim data-noescape class="stretch wide python">
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.staticfiles',
'myproject.apps.myapp.apps.MyappConfig',
]
ROOT_URLCONF = 'myproject.config.urls'
WSGI_APPLICATION = 'myproject.config.wsgi.application'
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
`settings.py` has also been updated.
This shows only the settings that have been updated to use the new namespaces.
The app in `INSTALLED_APPS` uses `myproject.apps`.
`urls` and `wsgi` modules use `myproject.config`.
</textarea>
</aside>
</section>
<section>
<h2>Project structure II</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
myproject
├── manage.py
├── MANIFEST.in
├── myproject
│ ├── __init__.py
│ ├── apps
│ │ ├── __init__.py
│ │ └── myapp
│ ├── config
│ ├── locale # NEW
│ ├── static # NEW
│ └── templates # NEW
├── setup.cfg
└── setup.py
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
Three new directories have also been added.
Notice that there are no `media` and `static_root` directories.
They could be created for development, but it would make no sense to have them for deployment.
Especially the `media` directory should not be inside the packaging, as it contains user uploads.
These would be deleted if a new version of the project will be installed.
</textarea>
</aside>
</section>
<section>
<h2>settings.py II</h2>
<pre>
<code data-trim data-noescape class="stretch wide python">
LOCALE_PATHS = (
os.path.join(BASE_DIR, 'locale'),
)
STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static'),
)
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'templates')],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
],
},
},
]
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
`settings.py` has been updated again to configure the paths for the three new directories.
</textarea>
</aside>
</section>
<section data-menu-title="requirements vs. setup.py">
<h2>requirements.txt<br>vs.<br>setup.py & setup.cfg</h2>
<aside class="notes" data-markdown>
<textarea data-template>
Usually a `requirements.txt` file is used to define the dependencies of a project.
And `setup.py` and `setup.cfg` are used for packaging libraries.
But if `setup.py` and `setup.cfg` are required to package the project, why not use them for both, dependencies and packaging?
</textarea>
</aside>
</section>
<section>
<h2>"Old" setup.py</h2>
<pre style="font-size: 0.3em">
<code data-trim data-noescape class="stretch python">
import os
import re
from codecs import open
from setuptools import find_packages, setup
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
def read(*paths):
"""Build a file path from *paths and return the contents."""
with open(os.path.join(*paths), 'r', 'utf-8') as f:
return f.read()
with open('myproject/__init__.py') as f:
contents = f.read()
metadata = dict(re.findall(r'__([a-z]+)__\s*=\s*[\'"]([^\'"]*)[\'"]', contents))
metadata['description'] = re.search(r'^"{3}(.*)"{3}', contents, re.DOTALL).group(1)
setup(
name='myproject',
version=metadata['version'],
description=metadata['description'],
long_description=read(BASE_DIR, 'README.rst'),
author=metadata['author'],
author_email=metadata['email'],
include_package_data=True,
install_requires=['arrow', 'bleach', 'Django', 'django-allauth', 'gunicorn', 'psycopg2', 'pytz', 'wagtail'],
license=metadata['license'],
url=metadata['url'],
packages=find_packages(exclude=['tests*']),
zip_safe=False,
classifiers=[
'Development Status :: 5 - Production/Stable',
'Environment :: Web Environment',
'Framework :: Django',
'Programming Language :: Python',
],
)
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
Usually a `setup.py` file looks like this. It contains not only static metadata for the package, but also some code.
The code is usually used to read information from other files.
</textarea>
</aside>
</section>
<section>
<h2>setup.cfg I</h2>
<pre>
<code data-trim data-noescape class="stretch ini">
[metadata]
name = myproject
version = 1.2.0
description = Lorem ipsum
long_description = file: README.rst
author = My Company
author_email = [email protected]
license = Other/Proprietary License
classifiers =
Development Status :: 5 - Production/Stable
Environment :: Web Environment
Framework :: Django
Programming Language :: Python
</code>
</pre>
<a href="https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files"><i class="fab fa-firefox"></i>Configuring setup() using setup.cfg files</a>
<aside class="notes" data-markdown>
<textarea data-template>
But since setuptools 30.3.0, released in December 2016, the `setup.cfg` file can be used to define the configuration.
As you can see this makes the file much more readable. And there is no code that can be executed!
Of course all machines that install the package need to have a version of setuptools installed that supports this feature.
But since we usually control the deployment environment this is no problem at all.
Below is the link to the corresponding setuptools documentation.
</textarea>
</aside>
</section>
<section>
<h2>setup.cfg II</h2>
<pre>
<code data-trim data-noescape class="stretch ini">
[options]
zip_safe = False
include_package_data = True
packages = myproject
install_requires =
arrow==0.12.1
bleach==2.1.3
Django==2.0.5
django-allauth==0.36.0
gunicorn==19.8.1
psycopg2==2.7.4
pytz==2018.4
wagtail==2.0.1
python_requires = >=3.6,<3.7
[bdist_wheel]
universal = 1
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
This is the second part of the `setup.cfg` file containing the options.
Because this is a project and not a library, no other distribution is consuming our dependencies.
So we can pin all of them. Notice it's also possible to pin the Python version.
This helps us to get reproducible and deterministic installations.
</textarea>
</aside>
</section>
<section>
<h2>"New" setup.py</h2>
<pre style="font-size: 0.3em">
<code data-trim data-noescape class="stretch python">
from setuptools import setup
setup()
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
Because all metadata and dependencies are now defined in `setup.cfg` we just need a boilerplate `setup.py` so that setuptools can build the package.
Nice, isn't it?
</textarea>
</aside>
</section>
<section>
<h2>bumpversion</h2>
<a href="https://pypi.org/project/bumpversion/"><img src="img/bumpversion.png"></a>
<aside class="notes" data-markdown>
<textarea data-template>
If you searching for a tool to bump the version of the package I highly recommend bumpversion.
bumpversion's configuration can also be added to `setup.cfg`.
</textarea>
</aside>
</section>
<section>
<h2>MANIFEST.in</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
include *.rst
graft myproject
prune myproject/media
prune myproject/static_root
exclude *.yml
exclude manage.py
global-exclude *.py[co]
global-exclude __pycache__
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
Finally there is the `MANIFEST.in` file.
It is used to control which files beside the Python source code go into the distribution.
It's evaluated from top to bottom and can be used to include or exclude single files or complete directories including their subdirectories.
Because the whole `myproject` directory is added all files in the `static` directory will be part of the package, too.
</textarea>
</aside>
</section>
<section>
<h2>check-manifest</h2>
<a href="https://pypi.org/project/check-manifest/"><img src="img/check-manifest.png"></a>
<aside class="notes" data-markdown>
<textarea data-template>
check-manifest is a tool to validate the `MANIFEST.in` file. It can also be configured with a separate section in `setup.cfg`.
</textarea>
</aside>
</section>
<section>
<h2>What about manage.py?</h2>
<pre class="fragment">
<code data-trim data-noescape class="stretch wide ini">
[options.entry_points]
console_scripts =
site-admin = django.core.management:execute_from_command_line
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
`manage.py` has been excluded in `MANIFEST.in` in the previous step. So how are we going to execute any commmands?
The answer is to create an entrypoint named `site-admin` in `setup.cfg` that executes the same code like `manage.py`.
Bonus: It can be executed from any directory!
</textarea>
</aside>
</section>
<section>
<h2>Building the package</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
python setup.py bdist_wheel
</code>
<code data-trim data-noescape class="stretch bash fragment" data-fragment-index="1">
ls dist
</code>
<code data-trim data-noescape class="stretch bash fragment" data-fragment-index="1">
myproject-1.2.0-py2.py3-none-any.whl
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
Building the package is one simple command.
The result is a wheel archive.
</textarea>
</aside>
</section>
</section>
<section>
<section data-menu-title="Installing the package">
<h2>Installing a packaged Django project</h2>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>pip-tools</h2>
<a href="https://pypi.org/project/pip-tools/"><img src="img/pip-tools.png"></a>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>pip-tools commands</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
pip-compile --output-file constraints.txt
</code>
<code data-trim data-noescape class="stretch bash fragment">
pip-compile --generate-hashes --output-file constraints.txt
</code>
<code data-trim data-noescape class="stretch bash fragment">
pip-sync constraints.txt
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>constraints.txt</h2>
<pre style="font-size: 0.33em">
<code data-trim data-noescape class="stretch bash">
#
# This file is autogenerated by pip-compile
# To update, run:
#
# pip-compile --output-file constraints.txt setup.py
#
arrow==0.12.1
beautifulsoup4==4.6.0 # via wagtail
bleach==2.1.3
defusedxml==0.5.0 # via python3-openid
django-allauth==0.36.0
django-modelcluster==4.1 # via wagtail
django-taggit==0.22.2 # via wagtail
django-treebeard==4.3 # via wagtail
django==2.0.5 # via django-allauth, django-treebeard, wagtail
djangorestframework==3.8.2 # via wagtail
draftjs-exporter==2.0.0 # via wagtail
gunicorn==19.8.1
html5lib==0.999999999 # via bleach, wagtail
oauthlib==2.1.0 # via requests-oauthlib
olefile==0.45.1 # via pillow
pillow==4.0.0 # via wagtail
psycopg2==2.7.4
python-dateutil==2.7.3 # via arrow
python3-openid==3.1.0 # via django-allauth
pytz==2018.4
requests-oauthlib==0.8.0 # via django-allauth
requests==2.13.0 # via django-allauth, requests-oauthlib, wagtail
six==1.11.0 # via bleach, html5lib, python-dateutil
unidecode==0.4.21 # via wagtail
wagtail==2.0.1
webencodings==0.5.1 # via html5lib
willow==1.1 # via wagtail
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
This is the generated `constraints.txt` file without hashes.
It makes it easy to distinguish between the project dependencies and transitive dependencies.
</textarea>
</aside>
</section>
<section>
<h2>Installing for development</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
python -m pip install -c constraints.txt -e .
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
This is how you install the package in your development environment.
The difference between a `requirements.txt` and a `constraints.txt` file is, that the latter is only which version is installed, not if it's installed or not.
The real requirements are still defined in `setup.cfg`.
</textarea>
</aside>
</section>
<section>
<h2>Installing development tools</h2>
<pre>
<code data-trim data-noescape class="stretch ini">
[options.extras_require]
dev =
bumpversion
django-debug-toolbar
flake8
</code>
<code data-trim data-noescape class="stretch bash fragment">
python -m pip install -c constraints.txt -e .[dev]
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>How to serve the package?</h2>
<ul>
<li>From the file system</li>
<li>Using any HTTP server</li>
<li>Using <a href="https://www.devpi.net/">devpi</a></li>
</ul>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>Installing on any server</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
python -m pip install -c constraints.txt myproject==1.2.0
</code>
<code data-trim data-noescape class="stretch bash fragment">
python -m pip install -c constraints.txt \
-f /path/to/wheel myproject==1.2.0
</code>
<code data-trim data-noescape class="stretch bash fragment">
python -m pip install -c constraints.txt \
--extra-index-url https://example.com myproject==1.2.0
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>How to change settings?</h2>
<ul>
<li class="fragment">Use environment variables</li>
<li class="fragment">Except for the secrets - use a vault for this if possible</li>
<li class="fragment">Python and Django solutions
<ul>
<li><a href="https://pypi.org/project/envdir/">envdir</a></li>
<li><a href="https://pypi.org/project/django-configurations/">django-configurations</a></li>
<li><a href="https://pypi.org/project/envparse/">envparse</a></li>
<li><a href="https://pypi.org/project/environ-config/">environ-config</a></li>
</ul>
</li>
</ul>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>Running a WSGI server</h2>
<pre>
<code data-trim data-noescape class="stretch bash">
gunicorn myproject.config.wsgi
</code>
</pre>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
</section>
<section>
<h2>Packaging tools comparison</h2>
<ul>
<li class="fragment">Use npm/yarn for JavaScript dependency management</li>
<li class="fragment">Python packages are the lowest common denominator</li>
<li class="fragment">conda can be used instead of pip to install a packaged Django project</li>
<li class="fragment">Use tools like pex or snapcraft</li>
<li class="fragment">Use platform package managers if necessary</li>
<li class="fragment">Use Docker if necessary</li>
</ul>
<aside class="notes" data-markdown>
<textarea data-template>
* npm/yarn
* Use webpack or another bundler to create JavaScript bundles for the frontend and put them into the `static` directory.
* Python
* Not all platforms have a package manager, but all platforms have Python!
* conda
* Packages can be installed without having Python installed in the first place
* Non-Python dependencies can be installed too
* Use tools like pex or snapcraft
* Use platform package managers if necessary
* Use Docker if necessary
</textarea>
</aside>
</section>
<section>
<h2>Summary</h2>
<ul>
<li class="fragment">Hosting solution independent</li>
<li class="fragment">Uses tools you already know and use to install your dependencies - prevents NIH syndrome</li>
<li class="fragment">Improves deployment to many servers</li>
<li class="fragment">Same release is used everywhere: Dev, CI, Staging, Production</li>
<li class="fragment">Easy rollback</li>
<li class="fragment">A built distribution requires no build step</li>
<li class="fragment">Avoids to install tools like git, gcc, gettext, Node.js etc.</li>
</ul>
<aside class="notes" data-markdown>
<textarea data-template>
</textarea>
</aside>
</section>
<section>
<h2>Thank you!</h2>
</section>
<section>
<h2>Resources</h2>
<p>
<a href="http://slides.keimlink.de">
<i class="fab fa-firefox"></i>slides.keimlink.de
</a>
</p>
<p>
<a href="https://github.com/keimlink">
<i class="fab fa-github"></i>keimlink
</a>
</p>
<p>
<a href="https://twitter.com/keimlink">
<i class="fab fa-twitter"></i>@keimlink
</a>
</p>
<p>
<a href="mailto:[email protected]">
<i class="fas fa-envelope"></i>[email protected]
</a>
</p>
<p class="creativecommons">
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
<i class="fab fa-creative-commons"></i>
<i class="fab fa-creative-commons-by"></i>
</a>
</p>
<p class="smaller">
This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>
</p>
<p class="smaller">
Built with <a href="https://github.com/keimlink/cookiecutter-reveal.js">cookiecutter-reveal.js</a>, <a href="https://github.com/hakimel/reveal.js">reveal.js</a>, <a href="https://github.com/denehyg/reveal.js-menu">reveal.js-menu</a>, <a href="https://fontawesome.com/">Font Awesome</a> and <a href="https://github.com/vorillaz/devicons">devicons</a>.
</p>
</section>
</div>
</div>
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.js"></script>
<script>
// More info about config & dependencies:
// - https://github.com/hakimel/reveal.js#configuration
// - https://github.com/hakimel/reveal.js#dependencies
Reveal.initialize({
history: true,
dependencies: [
{ src: 'plugin/markdown/marked.js' },
{ src: 'plugin/markdown/markdown.js' },
{ src: 'plugin/notes/notes.js', async: true },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
// Zoom in and out with Alt+click
{ src: 'plugin/zoom-js/zoom.js', async: true },
{ src: 'third_party_plugins/menu.js' }
],
menu: {
themes: true,
transitions: true,
openButton: false,
loadIcons: false
}
});
</script>
</body>
</html>