From Fedora Project Wiki
(Replaced content with "{{admon/important|This page is deprecated| All Fedora Modularity Documentation has moved to the new [https://docs.pagure.org/modularity/ Fedora Modularity Documentation we...")
 
Line 1: Line 1:
 
{{admon/important|This page is deprecated| All Fedora Modularity Documentation has moved to the new [https://docs.pagure.org/modularity/ Fedora Modularity Documentation website] with source hosted along side the code in the [https://pagure.io/modularity Fedora Modularity website git repository]}}
== Setting up PDC locally for Modularity development ==
 
To develop tooling for Modularity and test it, we want to have a local instance of PDC installed. The [https://github.com/product-definition-center/product-definition-center/blob/master/docs/source/development.rst upstream documentation] describes a couple of ways of doing that, this document describes how it can be done
[https://github.com/product-definition-center/product-definition-center/blob/master/docs/source/development.rst#option-2-start-it-on-virtualenv using a Python virtualenv], with some notable differences:
 
* The virtualenv won't have system-wide packages enabled. This is so that OS updates or upgrades have a reduced impact on the development environment, "reduced" because neither <code>koji</code> nor <code>rpm</code> Python modules lend themselves well to be installed into a virtualenv, so for the sake of simplicity we'll symlink the system-wide installed modules.
* We'll use the <code>modularity</code> branch of <code>productmd</code>, not the version that's [https://pypi.python.org/pypi/productmd available on PyPI].
 
=== Walkthrough ===
 
<ol>
<li>Install the necessary system-wide packages (if missing) using <code>dnf</code>, <code>yum</code> or similar:
  <pre>koji
python-virtualenvwrapper
rpm-python</pre>
If you just installed <code>python-virtualenvwrapper</code>, you need to restart the shell for it to take effect, i.e. install the <code>mkvirtualenv</code> and other shell functions, or <code>source /etc/profile.d/virtualenvwrapper.sh</code> manually.
 
The patternfly1 package is required by PDC but isn't part of the Fedora distribution. You'll need to add a copr repository with
<pre>dnf copr enable patternfly/patternfly1</pre> before you can install it with <pre>dnf install patternfly1</pre>
Some development packages of libraries are needed for the Python module dependencies to be installed as well. Here's the list of development packages needed on Fedora 23:
<pre>
cyrus-sasl-devel
glibc-devel
graphviz-devel
keyutils-libs-devel
krb5-devel
libcom_err-devel
libffi-devel
libgcrypt-devel
libgpg-error-devel
libselinux-devel
libxml2-devel
libxslt-devel
nspr-devel
nss-devel
nss-softokn-freebl-devel
nss-util-devel
openldap-devel
openssl-devel
pcre-devel
python-devel
xz-devel
zlib-devel
</pre>
</li>
<li>Create a workspace directory where all the checked out code repositories live, if you haven't done so already. We'll refer to that as <code>$WORKSPACE</code>.
<li>Make a virtualenv <code>modularity</code> for PDC development. This is one point where we deviate from the upstream docs:
  <pre>mkvirtualenv modularity</pre>
This activates the <code>modularity</code> virtualenv right away, leave it using the <code>deactivate</code> command, and activate it again with <code>workon modularity</code> later on.
</li>
<li>''Optional:'' Upgrade <code>pip</code> so it doesn't complain about the old version being installed all the time:
  <pre>pip install --upgrade pip</pre>
</li>
<li>Make the <code>modularity</code> branch of <code>productmd</code> available in the virtualenv.
  <ol>
  <li>Clone the repository into your workspace:
    <pre>cd "$WORKSPACE"
git clone --branch modularity https://github.com/lkocman/productmd.git</pre>
  </li>
  <li>Make the virtualenv use the checked out source:
<pre>cd productmd
python setup.py develop</pre>
  </li>
  </ol>
</li>
<li>Symlink the <code>koji</code> and <code>rpm</code> Python packages from the system into the virtualenv:
<pre>cdvirtualenv
cd lib/python2.7/site-packages
ln -s /usr/lib/python2.7/site-packages/koji koji
ln -s /usr/lib64/python2.7/site-packages/rpm rpm</pre>
If you use a 32bit system, the last line must be changed to:
<pre>ln -s /usr/lib/python2.7/site-packages/rpm rpm</pre>
</li>
<li>Install Python dependencies needed by <code>koji</code> into the virtualenv:
<pre>pip install pyOpenSSL python-krbV</pre>
</li>
<li>Get PDC and set it up.
  <ol>
  <li>Clone the PDC repository into your workspace:
<pre>cd "$WORKSPACE"
git clone https://github.com/product-definition-center/product-definition-center.git</pre>
  </li>
  <li>Install the dependencies needed for PDC development:
<pre>cd product-definition-center
pip install -r requirements/devel.txt</pre>
  </li>
  <li>Create the database and schema inside, this command also would migrate the schema to a new version if subsequent changes in PDC make this necessary:
<pre>./manage.py migrate</pre>
  </li>
  <li>Create a superuser for PDC:
<pre>./manage.py createsuperuser</pre>
This will ask you for a user name, email address and password. Going forward, we'll assume the user name is <code>superuser</code>.
  </li>
  <li>Set up local configuration so testing doesn't require authentication etc. for what would be privileged operations in a productive environment.
    <ol>
    <li>Copy the local configuration file from the template:
<pre>cd pdc
cp settings_local.py.dist settings_local.py</pre>
    </li>
    <li>Make some changes in <code>settings_local.py</code>:
      <ol>
      <li>Enable debugging, change this line: <pre>DEBUG = False</pre> to this one: <pre>DEBUG = True</pre></li>
      <li>Don't restrict connecting to PDC (it listens on the loopback device only, anyway), comment out the <code>ALLOWED_HOSTS</code> line: <pre>#ALLOWED_HOSTS = [...]</pre></li>
      <li>Make unauthenticated access user the <code>superuser</code> account, forego permissions checking. Add these lines to the end of the file:
<pre># mock login for debugging
DEBUG_USER = "superuser"
 
DISABLE_RESOURCE_PERMISSION_CHECK = True
 
del get_setting('REST_FRAMEWORK')['DEFAULT_PERMISSION_CLASSES']</pre>
      </li>
      </ol>
    </li>
    </ol>
  </li>
  <li>Start up the local PDC instance:
<pre>cd "$WORKSPACE"/product-definition-center
./manage.py runserver</pre>
  </li>
  <li>Manually create the <code>module</code> Variant Type in the PDC interface.
    <ol>
    <li>Go to [http://127.0.0.1:8000 http://127.0.0.1:8000] with your web browser, then go the administrative interface <code>👤 superuser</code> → <code>PDC Administration interface</code>.</li>
    <li>Locate <code>Release</code> → <code>Variant types</code>, click on <code>+ Add</code>, enter <code>module</code> as the name, click on <code>Save</code>.</li>
    </ol>
  </li>
  </ol>
</li>
</ol>
 
At this point, PDC should be set up and ready for working with modules.

Latest revision as of 07:57, 20 February 2017

This page is deprecated
All Fedora Modularity Documentation has moved to the new Fedora Modularity Documentation website with source hosted along side the code in the Fedora Modularity website git repository