mirror of https://github.com/mitsuhiko/flask.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
166 lines
6.6 KiB
166 lines
6.6 KiB
.. _distribute-deployment: |
|
|
|
Deploying with Distribute |
|
========================= |
|
|
|
`distribute`_, formerly setuptools, is an extension library that is |
|
commonly used to (like the name says) distribute Python libraries and |
|
extensions. It extends distutils, a basic module installation system |
|
shipped with Python to also support various more complex constructs that |
|
make larger applications easier to distribute: |
|
|
|
- **support for dependencies**: a library or application can declare a |
|
list of other libraries it depends on which will be installed |
|
automatically for you. |
|
- **package registry**: setuptools registers your package with your |
|
Python installation. This makes it possible to query information |
|
provided by one package from another package. The best known feature of |
|
this system is the entry point support which allows one package to |
|
declare an "entry point" another package can hook into to extend the |
|
other package. |
|
- **installation manager**: `easy_install`, which comes with distribute |
|
can install other libraries for you. You can also use `pip`_ which |
|
sooner or later will replace `easy_install` which does more than just |
|
installing packages for you. |
|
|
|
Flask itself, and all the libraries you can find on the cheeseshop |
|
are distributed with either distribute, the older setuptools or distutils. |
|
|
|
In this case we assume your application is called |
|
`yourapplication.py` and you are not using a module, but a :ref:`package |
|
<larger-applications>`. Distributing resources with standard modules is |
|
not supported by `distribute`_ so we will not bother with it. If you have |
|
not yet converted your application into a package, head over to the |
|
:ref:`larger-applications` pattern to see how this can be done. |
|
|
|
A working deployment with distribute is the first step into more complex |
|
and more automated deployment scenarios. If you want to fully automate |
|
the process, also read the :ref:`fabric-deployment` chapter. |
|
|
|
Basic Setup Script |
|
------------------ |
|
|
|
Because you have Flask running, you either have setuptools or distribute |
|
available on your system anyways. If you do not, fear not, there is a |
|
script to install it for you: `distribute_setup.py`_. Just download and |
|
run with your Python interpreter. |
|
|
|
Standard disclaimer applies: :ref:`you better use a virtualenv |
|
<virtualenv>`. |
|
|
|
Your setup code always goes into a file named `setup.py` next to your |
|
application. The name of the file is only convention, but because |
|
everybody will look for a file with that name, you better not change it. |
|
|
|
Yes, even if you are using `distribute`, you are importing from a package |
|
called `setuptools`. `distribute` is fully backwards compatible with |
|
`setuptools`, so it also uses the same import name. |
|
|
|
A basic `setup.py` file for a Flask application looks like this:: |
|
|
|
from setuptools import setup |
|
|
|
setup( |
|
name='Your Application', |
|
version='1.0', |
|
long_description=__doc__, |
|
packages=['yourapplication'], |
|
include_package_data=True, |
|
zip_safe=False, |
|
install_requires=['Flask'] |
|
) |
|
|
|
Please keep in mind that you have to list subpackages explicitly. If you |
|
want distribute to lookup the packages for you automatically, you can use |
|
the `find_packages` function:: |
|
|
|
from setuptools import setup, find_packages |
|
|
|
setup( |
|
... |
|
packages=find_packages() |
|
) |
|
|
|
Most parameters to the `setup` function should be self explanatory, |
|
`include_package_data` and `zip_safe` might not be. |
|
`include_package_data` tells distribute to look for a `MANIFEST.in` file |
|
and install all the entries that match as package data. We will use this |
|
to distribute the static files and templates along with the Python module |
|
(see :ref:`distributing-resources`). The `zip_safe` flag can be used to |
|
force or prevent zip Archive creation. In general you probably don't want |
|
your packages to be installed as zip files because some tools do not |
|
support them and they make debugging a lot harder. |
|
|
|
|
|
.. _distributing-resources: |
|
|
|
Distributing Resources |
|
---------------------- |
|
|
|
If you try to install the package you just created, you will notice that |
|
folders like `static` or `templates` are not installed for you. The |
|
reason for this is that distribute does not know which files to add for |
|
you. What you should do, is to create a `MANIFEST.in` file next to your |
|
`setup.py` file. This file lists all the files that should be added to |
|
your tarball:: |
|
|
|
recursive-include yourapplication/templates * |
|
recursive-include yourapplication/static * |
|
|
|
Don't forget that even if you enlist them in your `MANIFEST.in` file, they |
|
won't be installed for you unless you set the `include_package_data` |
|
parameter of the `setup` function to `True`! |
|
|
|
|
|
Declaring Dependencies |
|
---------------------- |
|
|
|
Dependencies are declared in the `install_requires` parameter as list. |
|
Each item in that list is the name of a package that should be pulled from |
|
PyPI on installation. By default it will always use the most recent |
|
version, but you can also provide minimum and maximum version |
|
requirements. Here some examples:: |
|
|
|
install_requires=[ |
|
'Flask>=0.2', |
|
'SQLAlchemy>=0.6', |
|
'BrokenPackage>=0.7,<=1.0' |
|
] |
|
|
|
I mentioned earlier that dependencies are pulled from PyPI. What if you |
|
want to depend on a package that cannot be found on PyPI and won't be |
|
because it is an internal package you don't want to share with anyone? |
|
Just still do as if there was a PyPI entry for it and provide a list of |
|
alternative locations where distribute should look for tarballs:: |
|
|
|
dependency_links=['http://example.com/yourfiles'] |
|
|
|
Make sure that page has a directory listing and the links on the page are |
|
pointing to the actual tarballs with their correct filenames as this is |
|
how distribute will find the files. If you have an internal company |
|
server that contains the packages, provide the URL to that server there. |
|
|
|
|
|
Installing / Developing |
|
----------------------- |
|
|
|
To install your application (ideally into a virtualenv) just run the |
|
`setup.py` script with the `install` parameter. It will install your |
|
application into the virtualenv's site-packages folder and also download |
|
and install all dependencies:: |
|
|
|
$ python setup.py install |
|
|
|
If you are developing on the package and also want the requirements to be |
|
installed, you can use the `develop` command instead:: |
|
|
|
$ python setup.py develop |
|
|
|
This has the advantage of just installing a link to the site-packages |
|
folder instead of copying the data over. You can then continue to work on |
|
the code without having to run `install` again after each change. |
|
|
|
|
|
.. _distribute: https://pypi.python.org/pypi/distribute |
|
.. _pip: https://pypi.python.org/pypi/pip |
|
.. _distribute_setup.py: http://python-distribute.org/distribute_setup.py
|
|
|