Subject: pgweb dev install hurdles

From: Josh Kupershmidt <[email-masked]>
Date: Sat, 19 May 2012 13:42:16 -0700

Hi all,

I finally got around to trying out pgweb locally, following the
instructions in dev_install.rst. The first hurdle I hit was due to
DATABASE_NAME not being set in settings_local.py, which results in the
manage.py exception:
"You need to specify NAME in your Django settings file."

Since step 3 of dev_install.rst recommends creating the "pgweb"
database for this application, the suggested overrides for
settings_local.py in step 4 should include a DATABASE_NAME pointing
there.

Next, while trying to load in community_login.sql per step 6 of the
dev_install instructions, I encountered this:

josh@vboxdeb:~/src/pgweb/sql$ psql pgweb -f community_login.sql
BEGIN
CREATE FUNCTION
CREATE FUNCTION
psql:community_login.sql:87: ERROR:  relation "users_old" does not exist
LINE 4: ...lower(username)=lower($1) UNION ALL SELECT 1 from users_old ...

I didn't see anywhere the "users_old" relation was defined, other than
a mention in ./tools/migrate/1_crunch_in_sql.sql. I was able to work
around this problem by making a dummy users_old table with the
appropriate columns, but perhaps this table should be included in the
schema?

Then, when I ran load_initial_data.sh, I ran into this:

Problem installing fixture './core/fixtures/data.yaml': Traceback
(most recent call last):
  File "/usr/lib/pymodules/python2.6/django/core/management/commands/loaddata.py",
line 172, in handle
    obj.save(using=using)

...  snip  ...

  File "/usr/lib/pymodules/python2.6/django/db/backends/postgresql_psycopg2/base.py",
line 44, in execute
    return self.cursor.execute(query, args)
IntegrityError: null value in column "firstreldate" violates not-null constraint
DETAIL:  Failing row contains (1, 8.4, 0, 2009-07-01,
release-8-4.html, f, t, null, null, null).

which corresponded to this error in my server log:

ERROR:  null value in column "firstreldate" violates not-null constraint
DETAIL:  Failing row contains (1, 8.4, 0, 2009-07-01,
release-8-4.html, f, t, null, null, null).
STATEMENT:  INSERT INTO "core_version" ("id", "tree", "latestminor",
"reldate", "relnotes", "current", "supported", "docsloaded",
"firstreldate", "eoldate") VALUES (1, '8.4', 0, '2009-07-01',
'release-8-4.html', false, true, NULL, NULL, NULL)

I hacked up ./pgweb/core/fixtures/data.yaml to include a
"firstreldate" (copied from "reldate", no idea if that was right) and
"eoldate" until load_initial_data.sh worked OK.

Attached is a patch containing the few fixes/kludges I used to get
pgweb running locally.

Josh
diff --git a/docs/dev_install.rst b/docs/dev_install.rst
new file mode 100644
index c45582c..8952fc9
*** a/docs/dev_install.rst
--- b/docs/dev_install.rst
*************** So, you're ready to contribute to pgweb,
*** 5,11 ****
  local working copy of the website code, so you have something to work
  with. Here's a quick step-by-step on how to do that:
  
! 1. Make sure you have downloaded and installed django *version 1.2*
     (or later). You will also need the dependencies *psycopg2*, *yaml*
     and *markdown* (these are python libraries, so prefix python- for Debian
     packages, for example).
--- 5,11 ----
  local working copy of the website code, so you have something to work
  with. Here's a quick step-by-step on how to do that:
  
! #. Make sure you have downloaded and installed django *version 1.2*
     (or later). You will also need the dependencies *psycopg2*, *yaml*
     and *markdown* (these are python libraries, so prefix python- for Debian
     packages, for example).
*************** with. Here's a quick step-by-step on how
*** 28,33 ****
--- 28,34 ----
  	NO_HTTPS_REDIRECT=True
  	SESSION_COOKIE_SECURE=False
  	SESSION_COOKIE_DOMAIN=None
+         DATABASE_NAME="pgweb"
  #. In the pgweb directory run the following command to create all
     tables and indexes, as well as create a superuser for your local
     installation::
diff --git a/pgweb/core/fixtures/data.yaml b/pgweb/core/fixtures/data.yaml
new file mode 100644
index bc8dc5b..36662f0
*** a/pgweb/core/fixtures/data.yaml
--- b/pgweb/core/fixtures/data.yaml
***************
*** 6,11 ****
--- 6,13 ----
     "relnotes": "release-8-4.html", 
     "tree": "8.4", 
     "reldate": "2009-07-01", 
+    "eoldate": "2014-07-01",
+    "firstreldate": "2009-07-01", 
     "latestminor": 0
    }
   }, 
***************
*** 16,21 ****
--- 18,25 ----
     "relnotes": "release-8-3-7.html", 
     "tree": "8.3", 
     "reldate": "2009-03-17", 
+    "eoldate": "2013-02-01",
+    "firstreldate": "2009-03-17", 
     "latestminor": 7
    }
   }, 
***************
*** 25,31 ****
    "fields": {
     "relnotes": "release-8-2-13.html", 
     "tree": "8.2", 
!    "reldate": "2009-03-17", 
     "latestminor": 13
    }
   }, 
--- 29,37 ----
    "fields": {
     "relnotes": "release-8-2-13.html", 
     "tree": "8.2", 
!    "reldate": "2009-03-17",
!    "eoldate": "2011-12-01", 
!    "firstreldate": "2009-03-17", 
     "latestminor": 13
    }
   }, 
***************
*** 36,41 ****
--- 42,49 ----
     "relnotes": "release.html#RELEASE-8-1-17", 
     "tree": "8.1", 
     "reldate": "2009-03-17", 
+    "eoldate" : "2010-11-01",
+    "firstreldate": "2009-03-17", 
     "latestminor": 17
    }
   }, 
***************
*** 46,51 ****
--- 54,61 ----
     "relnotes": "release.html#RELEASE-8-0-21", 
     "tree": "8.0", 
     "reldate": "2009-03-17", 
+    "eoldate": "2010-10-01",
+    "firstreldate": "2009-03-17", 
     "latestminor": 21
    }
   }, 
diff --git a/sql/varnish.sql b/sql/varnish.sql
new file mode 100644
index 3de9196..1b5f8d7
*** a/sql/varnish.sql
--- b/sql/varnish.sql
*************** BEGIN;
*** 2,8 ****
  
  --
  -- Create a function to purge from varnish cache
! -- By defalut this adds the object to a pgq queue,
  -- but this function can be replaced with a void one
  -- when running a development version.
  --
--- 2,8 ----
  
  --
  -- Create a function to purge from varnish cache
! -- By default this adds the object to a pgq queue,
  -- but this function can be replaced with a void one
  -- when running a development version.
  --

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 23 May 2012 15:26:59 +0200

> instructions in dev_install.rst. The first hurdle I hit was due to

Ah, great. Clearly these instructions haven't been updated along
changes, and were in need of some fixing :-)

> settings_local.py in step 4 should include a DATABASE_NAME pointing

Yup, correct.

> appropriate columns, but perhaps this table should be included in the

Hmm. That's really a part of the migration only and shouldn't be used
on a new system. What would be better would be to redefine the
community_login function not to use it I think. OTOH, in that case it
doesn't really work exactly the same way.

Hmm.

Yeah, i guess creating a dummy table is what will be needed. It won't
ever be re-run on the master after all...

> Then, when I ran load_initial_data.sh, I ran into this:

oh wow. Clearly nobody has run that for a while :-)

> Attached is a patch containing the few fixes/kludges I used to get

Thanks! Applied, including the changes for the SQL.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/