зеркало из https://github.com/mozilla/kitsune.git
[bug 1035319] Updated docs to swap vendor for peep.
This commit is contained in:
dean
Родитель
1c08befc23
Коммит
ed15d1e961
|
|
@ -63,8 +63,8 @@ Celery
|
|||
Installing
|
||||
----------
|
||||
|
||||
Celery (and Django-Celery) is part of our :ref:`vendor library
|
||||
<vendor-chapter>`. You shouldn't need to do any manual installation.
|
||||
Celery (and Django-Celery) is part of our dependencies.
|
||||
You shouldn't need to do any manual installation.
|
||||
|
||||
|
||||
Configuring and Running
|
||||
|
|
|
|||
|
|
@ -151,36 +151,22 @@ terminal window you use.
|
|||
Installing dependencies
|
||||
=======================
|
||||
|
||||
Compiled Packages
|
||||
-----------------
|
||||
|
||||
There are a small number of compiled packages, including the MySQL
|
||||
Python client.
|
||||
|
||||
For development, you should install these with ``pip``, but for
|
||||
other situations you may want to use your system package manager.
|
||||
|
||||
::
|
||||
$ pip install -r requirements/compiled.txt
|
||||
|
||||
If you want to use your system's package manager, you'll need to go
|
||||
through ``requirements/compiled.txt`` and install the dependencies by
|
||||
hand.
|
||||
|
||||
|
||||
Python Packages
|
||||
---------------
|
||||
|
||||
All the pure-Python requirements are provided in the ``vendor``
|
||||
directory, also known as the "vendor library". This makes the packages
|
||||
available to Python without installing them globally and keeps them
|
||||
pinned to known-compatible versions.
|
||||
All the pure-Python requirements are provided in the requirements
|
||||
directory. We use a tool called ``peep`` to install packages and make sure
|
||||
versions are pinned.
|
||||
|
||||
If you do not have a vendor library, see the section about getting the source
|
||||
above.
|
||||
::
|
||||
$ ./scripts/peep.py install -r requirements.txt
|
||||
|
||||
If you have any issues installing via ``peep``, be sure you have the required
|
||||
header files from the packages listed in the requirements section above.
|
||||
|
||||
For more information on ``peep``, refer to the `README
|
||||
<https://github.com/erikrose/peep>` on the Github page for the project.
|
||||
|
||||
See the :ref:`vendor library <vendor-chapter>` documentation for more
|
||||
information on getting the vendor lib and keeping it up to date.
|
||||
|
||||
Javascript Packages
|
||||
-------------------
|
||||
|
|
|
|||
|
|
@ -31,7 +31,6 @@ Part 2: Developer's Guide
|
|||
searchchapter
|
||||
armyofawesome
|
||||
karma
|
||||
vendor
|
||||
wikidocs
|
||||
osumo
|
||||
notes
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ and prod, and are not intended to beat on the site to find vulnerabilities.
|
|||
|
||||
You don't need a Selenium server to run these, and don't need to install
|
||||
anything more than a modern version of Firefox, and the dependencies in
|
||||
the vendor library.
|
||||
the requirements directory.
|
||||
|
||||
These tests use Django's `Live Server TestCase`_ class as a base, which
|
||||
causes Django to run a real http server for some of it's tests, instead
|
||||
|
|
|
|||
172
docs/vendor.rst
172
docs/vendor.rst
|
|
@ -1,172 +0,0 @@
|
|||
.. _vendor-chapter:
|
||||
|
||||
==============
|
||||
Vendor Library
|
||||
==============
|
||||
|
||||
To help make setup faster and deployment easier, we pull all of our
|
||||
pure-Python dependencies into a "vendor library" (``kitsune/vendor``)
|
||||
in the kitsune repository and add them to the path in ``manage.py``.
|
||||
|
||||
The vendor library used to be optional, with a virtualenv option
|
||||
available, as well. While it's still possible to install the compiled
|
||||
requirements in a virtualenv, we've decided to simplify
|
||||
docs/setup/tooling and encourage environments to be as similar to
|
||||
production as possible, by settling on the vendor library as the only
|
||||
method for managing dependencies.
|
||||
|
||||
|
||||
Getting the Vendor Library and Keeping Up-to-Date
|
||||
=================================================
|
||||
|
||||
If you cloned Kitsune with ``--recursive``, you already have the
|
||||
vendor library in ``vendor/``.
|
||||
|
||||
If you didn't clone with ``--recursive``, or need to update the vendor
|
||||
library (or other submodules), just run::
|
||||
|
||||
$ git submodule update --init --recursive
|
||||
|
||||
Aliasing that to something short (e.g. ``gsu``) is recommended.
|
||||
|
||||
|
||||
Updating the Vendor Library
|
||||
===========================
|
||||
|
||||
From time to time we need to update libraries, either for new versions
|
||||
of libraries or to add a new library. There are two ways to do
|
||||
that. The easiest and prefered way is pure git.
|
||||
|
||||
|
||||
Using Git Submodules
|
||||
--------------------
|
||||
|
||||
Using git submodules is prefered because it is much easier to
|
||||
maintain, and it keeps the repository size small. Upgrading is as
|
||||
simple as updating a submodule.
|
||||
|
||||
|
||||
Updating a Library with Git Submodules
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If the library is in ``vendor/src``, it was pulled directly from
|
||||
version control, and if that version control was git, updating the
|
||||
submodule is as easy as::
|
||||
|
||||
$ cd vendor/src/$LIBRARY
|
||||
$ git fetch origin
|
||||
$ git checkout <REFSPEC>
|
||||
$ cd ../..
|
||||
$ git add vendor/src/$LIBRARY
|
||||
$ git ci -m "Updating $LIBRARY"
|
||||
|
||||
Easy! Just like updating any other git submodule.
|
||||
|
||||
|
||||
Adding a New Library with Git Submodules
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Technically this can be done with ``pip install --no-install`` but
|
||||
there's an even easier method when installing a new library from a git
|
||||
repo::
|
||||
|
||||
$ cd vendor/src
|
||||
$ git clone https://<repo>
|
||||
$ cd ../..
|
||||
$ vendor/addsubmodules.sh
|
||||
$ vim vendor/kitsune.pth # Add the new library's path
|
||||
$ git add vendor/kitsune.pth
|
||||
$ git ci -m "Adding $LIBRARY"
|
||||
|
||||
|
||||
.. Note::
|
||||
|
||||
Use the ``git://`` url for a repository and not the ``http://``
|
||||
one. The git protocol is more resilient and faster to clone over.
|
||||
|
||||
Don't use the ``git@`` url. It will only bring you pain.
|
||||
|
||||
|
||||
Removing a Library from ``vendor/src``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Removing an existing submodule is easy if you follow these steps in the
|
||||
right order::
|
||||
|
||||
$ rm -rf vendor/src/<submodule>
|
||||
$ git submodule deinit vendor/src/<submodule>
|
||||
$ git rm vendor/src/<submodule>
|
||||
$ vim vendor/kitsune.pth # Remove the line with ``src/<submodule>``
|
||||
$ git ci -am "Removing <submodule> from vendor."
|
||||
|
||||
|
||||
Using PyPI
|
||||
----------
|
||||
|
||||
Sometimes a library isn't in a git repository. It, sadly,
|
||||
happens. Maybe you can find a git mirror? If not, it might as well be
|
||||
installed from PyPI.
|
||||
|
||||
|
||||
Updating a Library from PyPI
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The easiest way to update a library from PyPI is to remove it
|
||||
completely and then install the new version.
|
||||
|
||||
::
|
||||
|
||||
$ cd vendor/packages
|
||||
$ git rm -r $LIBRARY
|
||||
$ cd ..
|
||||
$ git ci -m "Removing version $VERSION of $LIBRARY"
|
||||
$ cd ..
|
||||
|
||||
After removing the old version, go ahead and install the new one::
|
||||
|
||||
$ pip install --no-install --build=vendor/packages --src=vendor/src -I $LIBRARY
|
||||
|
||||
Finally, add the new library to git::
|
||||
|
||||
$ cd vendor
|
||||
$ git add packages
|
||||
$ git ci -m "Adding version $VERSION of $LIBRARY"
|
||||
|
||||
|
||||
.. warning::
|
||||
|
||||
**Caveat developer!** Sometimes a library has dependencies that are
|
||||
already installed in the vendor repo. You may need to remove
|
||||
several of them to make everything work easily.
|
||||
|
||||
|
||||
Adding a Library from PyPI
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Adding a new library from PyPI is easy using pip::
|
||||
|
||||
$ pip install --no-install --build=vendor/packages --src=vendor/src -I $LIBRARY
|
||||
$ cd vendor
|
||||
$ git add packages
|
||||
$ vim kitsune.pth # Add any new libraries' paths.
|
||||
$ git ci -m "Adding $LIBRARY"
|
||||
|
||||
Make sure you add any dependencies from the new library, as well.
|
||||
|
||||
|
||||
Requirements Files
|
||||
==================
|
||||
|
||||
There are a few requirements that are not included in the vendor
|
||||
library because they need to be (or can be, for performance benefits)
|
||||
compiled (or have compiled dependencies themselves).
|
||||
|
||||
You can :ref:`install <hacking-howto-chapter>` these in a virtualenv
|
||||
or at the system level by running::
|
||||
|
||||
$ pip install -r requirements/compiled.txt
|
||||
|
||||
If you want to run coverage builds or are having issues with tests,
|
||||
you can run::
|
||||
|
||||
$ pip install -r requirements/tests-compiled.txt
|
||||
|
|
@ -21,9 +21,8 @@ Overview
|
|||
========
|
||||
|
||||
Setting up Kitsune to run as a WSGI application is fairly
|
||||
straightforward. You will need to install the requirements and clone
|
||||
the vendor repo as described in :ref:`the installation chapter
|
||||
<hacking-howto-chapter>`.
|
||||
straightforward. You will need to install the requirements as described
|
||||
in :ref:`the installation chapter <hacking-howto-chapter>`.
|
||||
|
||||
There are 3 steps once Kitsune is installed:
|
||||
|
||||
|
|
@ -59,7 +58,7 @@ In the Apache config (or ``<VirtualHost>``) you will need the following:
|
|||
|
||||
Alias /media/ "/path/to/kitsune/media/"
|
||||
Alias /admin-media/ \
|
||||
"/path/to/kitsune/vendor/src/django/django/contrib/admin/media/"
|
||||
"/path/to/virtualenv/lib/python<version>/site-packages/django/django/contrib/admin/media/"
|
||||
|
||||
WSGISocketPrefix /var/run/wsgi
|
||||
|
||||
|
|
@ -127,7 +126,7 @@ and executable.
|
|||
|
||||
By default, ``product_details`` stores the JSON files in::
|
||||
|
||||
vendor/src/django-mozilla-product-details/product_details/json
|
||||
path/to/virtualenv/lib/python<version>/site=packages/django-mozilla-product-details/product_details/json
|
||||
|
||||
This is configurable. If you have multiple web servers, they should share this
|
||||
data. You can set the ``PROD_DETAILS_DIR`` variable in
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче