---
title: "Zaawansowany tutorial: Jak pisać aplikacje wielokrotnego użytku"
version: 5.1
locale: pl
source: https://docs.djangoproject.com/pl/5.1/intro/reusable-apps/
canonical: https://djangodocs.dev/pl/5.1/intro/reusable-apps/
---
# Zaawansowany tutorial: Jak pisać aplikacje wielokrotnego użytku

Ten tutorial dla zaawansowanych zaczyna się, gdzie [Tutorial 8](/pl/5.1/intro/tutorial07/) się skończył. Będziemy przerabiać naszą web-ankietę na samodzielny pakiet Pythona, który będziesz mógł wykorzystać w nowym projekcie i którym będziesz mógł podzielić się z innymi.

If you haven’t recently completed Tutorials 1–8, we encourage you to review
these so that your example project matches the one described below.

## Możliwość ponownego użycia ma znaczenie

Zaprojektować, zbudować, przetestować i utrzymywać aplikację webową to bardzo dużo pracy. Wiele projektów w Pythonie i Django napotyka wspólne problemy. Czy nie byłoby super, jeśli moglibyśmy oszczędzić części tej powtarzanej pracy?

Ponowne wykorzystanie to sposób na życie w Pythonie. [Python Package Index (PyPI)](https://pypi.org/) zawiera obszerny zakres pakietów, które możesz wykorzystać w swoich własnych pythonowych programach. Sprawdź w [Django Packages](https://djangopackages.org) istniejące aplikacje gotowe do wykorzystania, które mógłbyś wcielić w swój projekt. Samo Django także jest normalnym pythonowym pakietem. To znaczy, że możesz wziąć istniejące pakiety Pythona lub aplikacje Django i złożyć z nich swój własny projekt webowy. Musisz jedynie napisać części, które uczynią twój projekt unikalnym.

Powiedzmy, że zaczynałeś nowy projekt, który potrzebował aplikacji z ankietą, takiej jak ta, nad którą pracowaliśmy. Jak uczynić tą aplikację gotową do wykorzystania przez innych? Na szczęście, jesteśmy już na dobrej drodze. W [Tutorialu 1](/pl/5.1/intro/tutorial01/) widzieliśmy jak możemy wydzielić ankiety z URLconfa na poziomie projektu przez użycie `include`. W tym tutorialu poczynimy dalsze kroki, aby uczynić aplikację łatwą do użycia w nowych projektach i gotową do publikacji, aby inni mogli ją zainstalować i używać.

> **Pakiet? Aplikacja?**
>
> Pythonowy [package](https://docs.python.org/3/glossary.html#term-package) jest sposobem na zgrupowanie związanego kodu Pythona na potrzeby łatwego ponownego użycia. Pakiet zawiera jeden lub więcej plików z kodem Pythona (znane także jako „moduły”).
>
> Pakiet można zaimportować przez `import foo.bar` lub `from foo import bar`. Aby katalog (jak `polls`) stał się pakietem, musi zawierać specjalny plik `__init__.py`, który może być pusty.
>
> *Aplikacja* Django jest pakietem Pythona, który jest szczególnie przeznaczony do użycia w projekcie Django. Aplikacja może używać powszechnych w Django konwencji, jak posiadanie podmodułów `models`, `tests`, `urls` i `views`.
>
> Dalej będziemy używać pojęcia *pakietowanie*, aby opisać proces robienia pakietu Pythona łatwego do instalacji dla innych. Mamy świadomość, że może to być nieco mylące.

## Twój projekt i twoja aplikacja do ponownego wykorzystania

Po poprzednich tutorialach, nasz projekt powinien wyglądać tak:

```text
djangotutorial/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        asgi.py
        wsgi.py
    polls/
        __init__.py
        admin.py
        apps.py
        migrations/
            __init__.py
            0001_initial.py
        models.py
        static/
            polls/
                images/
                    background.png
                style.css
        templates/
            polls/
                detail.html
                index.html
                results.html
        tests.py
        urls.py
        views.py
    templates/
        admin/
            base_site.html
```

You created `djangotutorial/templates` in [Tutorial 7](/pl/5.1/intro/tutorial07/), and `polls/templates` in
[Tutorial 3](/pl/5.1/intro/tutorial03/). Now perhaps it is clearer why we chose
to have separate template directories for the project and application:
everything that is part of the polls application is in `polls`. It makes the
application self-contained and easier to drop into a new project.

Katalog `polls` mógłby być teraz skopiowany do nowego projektu Django i od razu użyty. Ale nie jest zupełnie gotowy do bycia opublikowanym. Na tę potrzebę, musimy spakować naszą aplikację, aby ułatwić innym jej instalację.

## Instalowanie narzędzi

Bieżący stan pakietowania w Pythonie jest nieco zagmatwany przez wiele narzędzi. Na potrzeby tego tutorialu, użyjemy [setuptools](https://pypi.org/project/setuptools/), aby zbudować nasz pakiet. Są one zalecanym narzędziem pakietowania (zmergowane z forkiem `distribute`). Będziemy też używać [pip](https://pypi.org/project/pip/), aby go zainstalować i odinstalować. Powinieneś teraz zainstalować te dwa pakiety. Jeśli potrzebujesz pomocy, możesz zajrzeć do [jak zainstalować Django używając pipa](/pl/5.1/topics/install/#installing-official-release). W ten sam sposób możesz zainstalować `setuptools`.

## Pakowanie twojej aplikacji

Pythonowe *pakietowanie* oznacza przygotowane twojej aplikacji w określonym formacie, który będzie mógł być prosto zainstalowany i użyty. Samo Django jest zapakowane właśnie w ten sposób. Dla małej aplikacji jak ankiety, ten proces nie jest zbyt skomplikowany.

1. First, create a parent directory for the package, outside of your Django
   project. Call this directory `django-polls`.

   > **Wybór nazwy dla twojej aplikacji**
   >
   > When choosing a name for your package, check PyPI to avoid naming
   > conflicts with existing packages. We recommend using a `django-`
   > prefix for package names, to identify your package as specific to
   > Django, and a corresponding `django_` prefix for your module name. For
   > example, the `django-ratelimit` package contains the
   > `django_ratelimit` module.
   >
   > Etykiety aplikacji (czyli ostatnia część kropkowanej ścieżki do pakietów aplikacji) *musi* być unikalna w [`INSTALLED_APPS`](/pl/5.1/ref/settings/#std-setting-INSTALLED_APPS). Unikaj używania takich samych etykiet jak którykolwiek z [pakietów contrib](/pl/5.1/ref/contrib/), na przykład `auth`, `admin` lub `messages`.
2. Move the `polls` directory into `django-polls` directory, and rename it
   to `django_polls`.
3. Edit `django_polls/apps.py` so that [`name`](/pl/5.1/ref/applications/#django.apps.AppConfig.name) refers to the
   new module name and add [`label`](/pl/5.1/ref/applications/#django.apps.AppConfig.label) to give a short name for
   the app:

   *`django-polls/django_polls/apps.py`*

   ```python
   from django.apps import AppConfig

   class PollsConfig(AppConfig):
       default_auto_field = "django.db.models.BigAutoField"
       name = "django_polls"
       label = "polls"
   ```
4. Stwórz plik `django-polls/README.rst` o następującej treści:

   *`django-polls/README.rst`*

   ```rst
   ============
   django-polls
   ============

   django-polls is a Django app to conduct web-based polls. For each
   question, visitors can choose between a fixed number of answers.

   Detailed documentation is in the "docs" directory.

   Quick start
   -----------

   1. Add "polls" to your INSTALLED_APPS setting like this::

       INSTALLED_APPS = [
           ...,
           "django_polls",
       ]

   2. Include the polls URLconf in your project urls.py like this::

       path("polls/", include("django_polls.urls")),

   3. Run ``python manage.py migrate`` to create the models.

   4. Start the development server and visit the admin to create a poll.

   5. Visit the ``/polls/`` URL to participate in the poll.
   ```
5. Stwórz plik `django-polls/LICENSE`. Wybór licencji jest poza zakresem tego tutorialu, ale wystarczy powiedzieć, że kod wydany publicznie bez licencji jest *bezużyteczny*. Django i wiele kompatybilnych z Django aplikacji są rozpowszechniane na licencji BSD, aczkolwiek ty możesz wybrać swoją własną licencję. Bądź tylko świadom, że wybór licencji będzie miał wpływ na to, kto może używać twój kod.
6. Next we’ll create the `pyproject.toml` file which details how to build and
   install the app. A full explanation of this file is beyond the scope of this
   tutorial, but the [Python Packaging User Guide](https://packaging.python.org/guides/writing-pyproject-toml/) has a good
   explanation. Create the `django-polls/pyproject.toml` file with the
   following contents:

   *`django-polls/pyproject.toml`*

   ```toml
   [build-system]
   requires = ["setuptools>=77.0.3"]
   build-backend = "setuptools.build_meta"

   [project]
   name = "django-polls"
   version = "0.1"
   dependencies = [
       "django>=X.Y",  # Replace "X.Y" as appropriate
   ]
   description = "A Django app to conduct web-based polls."
   readme = "README.rst"
   license = "BSD-3-Clause"
   requires-python = ">= 3.10"
   authors = [
       {name = "Your Name", email = "yourname@example.com"},
   ]
   classifiers = [
       "Environment :: Web Environment",
       "Framework :: Django",
       "Framework :: Django :: X.Y",  # Replace "X.Y" as appropriate
       "Intended Audience :: Developers",
       "Operating System :: OS Independent",
       "Programming Language :: Python",
       "Programming Language :: Python :: 3",
       "Programming Language :: Python :: 3 :: Only",
       "Programming Language :: Python :: 3.10",
       "Programming Language :: Python :: 3.11",
       "Programming Language :: Python :: 3.12",
       "Programming Language :: Python :: 3.13",
       "Topic :: Internet :: WWW/HTTP",
       "Topic :: Internet :: WWW/HTTP :: Dynamic Content",
   ]

   [project.urls]
   Homepage = "https://www.example.com/"
   ```
7. Many common files and Python modules and packages are included in the
   package by default. To include additional files, we’ll need to create a
   `MANIFEST.in` file. To include the templates and static files, create a
   file `django-polls/MANIFEST.in` with the following contents:

   *`django-polls/MANIFEST.in`*

   ```text
   recursive-include django_polls/static *
   recursive-include django_polls/templates *
   ```
8. It’s optional, but recommended, to include detailed documentation with your
   app. Create an empty directory `django-polls/docs` for future
   documentation.

   Zwróć uwagę, że katalog `docs` nie zostanie zawarty w twoim pakiecie dopóki nie dodasz do niego jakichś plików. Wiele aplikacji Django dostarcza swoją dokumentację online przez strony takie jak [readthedocs.org](https://readthedocs.org).

   Many Python projects, including Django and Python itself, use [Sphinx](https://www.sphinx-doc.org/en/master/usage/quickstart.html) to build
   their documentation. If you choose to use Sphinx you can link back to the
   Django documentation by configuring [Intersphinx](https://www.sphinx-doc.org/en/master/usage/quickstart.html#intersphinx)
   and including a value for Django in your project’s `intersphinx_mapping`
   value:

   ```
   intersphinx_mapping = {
       # ...
       "django": (
           "https://docs.djangoproject.com/en/stable/",
           None,
       ),
   }
   ```

   With that in place, you can then cross-link to specific entries, in the
   same way as in the Django docs, such as
   „`` :attr:`django.test.TransactionTestCase.databases` ``”.
9. Check that the [build](https://pypi.org/project/build/) package is installed (`python -m pip install
   build`) and try building your package by running `python -m build` inside
   `django-polls`. This creates a directory called `dist` and builds your
   new package into source and binary formats, `django_polls-0.1.tar.gz` and
   `django_polls-0.1-py3-none-any.whl`.

Aby dowiedzieć się więcej na temat pakowania, zobacz tutorial [Packaging Python Projects](https://packaging.python.org/tutorials/packaging-projects/).

## Używanie twojego własnego pakietu

Odkąd przenieśliśmy katalog `polls` poza projekt, nie działa. Naprawimy to teraz instalując nasz nowy pakiet `django-polls`.

> **Instalowanie jako bibliotekę użytkownika**
>
> Poniższe kroki zainstalują `django-polls` jako bibliotekę użytkownika. Instalacja bibliotek per użytkownik posiada sporo zalet w porównaniu do instalacji paczek per system jak np. możliwość instalacji bibliotek w systemie, w którym nie posiadasz uprawnień administracyjnych oraz zapobieganie wpływu biblioteki na system i innych jego użytkowników.
>
> Pamiętaj, że instalacja per użytkownik nadal może wpłynąć na narzędzia systemowe uruchamiane przez tego samego użytkownika, więc używanie środowiska wirtualnego jest bardziej niezawodnym rozwiązaniem (patrz niżej).

1. Aby zainstalować pakiet, użyj pipa (już [go zainstalowałeś](#installing-reusable-apps-prerequisites), prawda?):

   ```shell
   python -m pip install --user django-polls/dist/django_polls-0.1.tar.gz
   ```
2. Update `mysite/settings.py` to point to the new module name:

   ```
   INSTALLED_APPS = [
       "django_polls.apps.PollsConfig",
       ...,
   ]
   ```
3. Update `mysite/urls.py` to point to the new module name:

   ```
   urlpatterns = [
       path("polls/", include("django_polls.urls")),
       ...,
   ]
   ```
4. Run the development server to confirm the project continues to work.

## Publikowanie twojej aplikacji

Teraz, kiedy już spakowaliśmy i przetestowaliśmy `django-polls`, są gotowe do podzielenia się ze światem! Gdyby to nie był tylko przykład, mógłbyś teraz:

- Wyślij e-mail z pakietem do znajomego.
- Załaduj pakiet na swoją stronę.
- Opublikuj pakiet w publicznym repozytorium, takim jak [Python Package Index (PyPI)](#the-python-package-index-pypi). [packaging.python.org](https://packaging.python.org) ma [dobry tutorial](https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives) na ten temat.

## Instalowanie pakietów Pythona z wirtualnym środowiskiem

Earlier, we installed `django-polls` as a user library. This has some
disadvantages:

- Modyfikowanie bibliotek użytkownika może wpłynąć na inne oprogramowanie Python w twoim systemie.
- Nie będziesz w stanie uruchamiać wielu wersji tego pakietu (lub innych o takiej samej nazwie).

Zazwyczaj takie sytuacje zdarzają się tylko kiedy utrzymujesz kilka projektów Django. W takiej sytuacji najlepszym rozwiązaniem jest venv \<python:tutorial/venv\>. To narzędzie pozwala utrzymywać wiele izolowanych środowisk Pythona, każdy ze swoimi własnymi kopiami bibliotek i przestrzeniami nazw dla pakietów.
