Getting Trac running in a venv

[Mike Dewhirst]

I had to stop using Trac when I upgraded the machine to Python3. Call
that machine pq3 and Trac is currently off the air.

The reason is pq3 also runs a couple of Django staging servers which
have moved beyond version 1.11 and are therefore no longer capable of
running on Python 2.7.

I can't wait for Trac on Python3 so I think my choices are ...

1. Set up a Python 2.7 venv on pq3 and re-install Trac there

... OR install Python 2.7 on a separate machine - call it pq2 - and ...

2. Redirect Trac traffic to pq2 from pq3 using Apache redirection

3. Redirect Trac traffic to pq2 from the router using different port
forwarding - say 4430

pq2 and pq3 are both Ubuntu 18.04 and Apache 2.4 on both. Both machines
are behind the same router and I can only direct web traffic to one and
that has to be pq3. The Trac database is on pq3.

What do you recommend is the easiest course?

I plan to adopt Trac for Python3 as soon as it is released and retire
pq2 permanently.

Thanks for any advice.

Cheers

Mike

[Mickaël Bucas]

Hi Mike

I encountered the same issue when I changed my system Python to
version 3.6, so I'm currently running Trac 1.2 in a virtualenv I've
created with the following commands :
--------------8<--------------
mkdir -p /var/lib/trac/$PROJECT/venv
virtualenv -p python2 /var/lib/trac/$PROJECT/venv
source /var/lib/trac/$PROJECT/venv/bin/activate
pip install trac==1.2.2 mysql-python Babel pygments
# Subversion bindings
ln -s /usr/lib64/python2.7/site-packages/libsvn
/var/lib/trac/$PROJECT/venv/lib/python2.7/site-packages/
ln -s /usr/lib64/python2.7/site-packages/svn
/var/lib/trac/$PROJECT/venv/lib/python2.7/site-packages/
--------------8<--------------

To start Trac, I use `tracd`, but it must run when the virtualenv is activated
--------------8<--------------
start-stop-daemon --start \
--user ${TRACD_USER:-tracd} --group ${TRACD_GROUP:-tracd} \
--pidfile /var/run/tracd-${TRACD_PROJECT}.pid --make-pidfile --background \
--exec /opt/bin/tracd-start-server.sh -- \
${TRACD_PROJECT} ${TRACD_PORT} ${TRACD_OPTS}
--------------8<--------------

`/opt/bin/tracd-start-server.sh` contains :
--------------8<--------------
# Parameters
TRACD_PROJECT=$1
shift
TRACD_PORT=$1
shift
TRACD_OPTS=$*

# Virtualenv
source /var/lib/trac/${TRACD_PROJECT}/venv/bin/activate

export PYTHON_EGG_CACHE="/var/lib/trac/${TRACD_PROJECT}/trac/egg-cache"

# Exec to keep the PID recorded by start-stop-daemon
exec /var/lib/trac/${TRACD_PROJECT}/venv/bin/tracd \
-p ${TRACD_PORT} --single-env ${TRACD_OPTS} \
--base-path=/trac/${TRACD_PROJECT} \
/var/lib/trac/${TRACD_PROJECT}/trac \
>> /var/lib/trac/${TRACD_PROJECT}/trac/log/tracd-output.log 2>&1
--------------8<--------------

Then you must tell Apache to proxy to the `tracd` server :
--------------8<--------------
<Location /trac/$PROJECT >
# Proxy to tracd
ProxyPass http://$SITE:$NUMBER/trac/$PROJECT ttl=60
ProxyPassReverse http://$SITE:$NUMBER/trac/$PROJECT
</Location>
--------------8<--------------

So far it works as expected.

I still have to work on upgrading to Trac 1.4, whose dependencies are
different. And I will have to check if the extensions I use are still
working.

Best regards

Mickaël Bucas

[Jonathan Laufersweiler]

Another option would be to use PyInstaller to package up a minimal 2.7 interpreter with the bytecode for Trac and its dependencies into a into a stand-alone executable package. This would make updating Trac more of a chore, but would simplify the service & routing setup compared to the venv approach. YMMV, of course. --JonL

[Dimitri Maziuk]

On 10/9/19 2:06 PM, Jonathan Laufersweiler wrote:
> Another option would be to use PyInstaller to package up a minimal 2.7
> interpreter with the bytecode for Trac and its dependencies into a into a
> stand-alone executable package. This would make updating Trac more of a
> chore, but would simplify the service & routing setup compared to the venv
> approach. YMMV, of course.

Really...

https://hub.docker.com/r/mwaeckerlin/trac
https://hub.docker.com/r/stephenhsu/trac/
https://github.com/solsson/docker-trac
etc.

Bitnami claims to have a container too but I don't see a link on their
trac page.

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

[Mike Dewhirst]

Mickaël

You are a hero!

That means thank you very much. Your documentation skills are as amazing as your dev-ops skills.

I struggle with both ...

Cheers

Mike

[Mike Dewhirst]

On 10/10/2019 6:06 am, Jonathan Laufersweiler wrote:
> Another option would be to use PyInstaller to package up a minimal 2.7
> interpreter with the bytecode for Trac and its dependencies into a
> into a stand-alone executable package. This would make updating Trac
> more of a chore, but would simplify the service & routing setup
> compared to the venv approach. YMMV, of course. --JonL

I have never used PyInstaller so I'll keep this up my sleeve in case I
run into insurmountable trouble with Mickaël's venv approach. I'm not
planning on updating until Trac is stable on Py3 so that's a plus.

Thank you Jon

Cheers

Mike

>
> On Tuesday, October 8, 2019 at 10:04:32 PM UTC-5, Mike Dewhirst wrote:
>
> I had to stop using Trac when I upgraded the machine to Python3. Call
> that machine pq3 and Trac is currently off the air.
>
> The reason is pq3 also runs a couple of Django staging servers which
> have moved beyond version 1.11 and are therefore no longer capable of
> running on Python 2.7.
>
> I can't wait for Trac on Python3 so I think my choices are ...
>
> 1. Set up a Python 2.7 venv on pq3 and re-install Trac there
>
> ... OR install Python 2.7 on a separate machine - call it pq2 -
> and ...
>
> 2. Redirect Trac traffic to pq2 from pq3 using Apache redirection
>
> 3. Redirect Trac traffic to pq2 from the router using different port
> forwarding - say 4430
>
> pq2 and pq3 are both Ubuntu 18.04 and Apache 2.4 on both. Both
> machines
> are behind the same router and I can only direct web traffic to
> one and
> that has to be pq3. The Trac database is on pq3.
>
> What do you recommend is the easiest course?
>
> I plan to adopt Trac for Python3 as soon as it is released and retire
> pq2 permanently.
>
> Thanks for any advice.
>
> Cheers
>
> Mike
>

> --
> You received this message because you are subscribed to the Google
> Groups "Trac Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to trac-users+...@googlegroups.com
> <mailto:trac-users+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/trac-users/02acdc83-8b3f-4763-adca-114f224fe7d6%40googlegroups.com
> <https://groups.google.com/d/msgid/trac-users/02acdc83-8b3f-4763-adca-114f224fe7d6%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Mike Dewhirst]

On 10/10/2019 7:20 am, 'Dimitri Maziuk' via Trac Users wrote:
> On 10/9/19 2:06 PM, Jonathan Laufersweiler wrote:
>> Another option would be to use PyInstaller to package up a minimal 2.7
>> interpreter with the bytecode for Trac and its dependencies into a into a
>> stand-alone executable package. This would make updating Trac more of a
>> chore, but would simplify the service & routing setup compared to the venv
>> approach. YMMV, of course.
> Really...

Dimitri thank you. I had not thought of Docker because I have avoided
thinking of Docker for years. That means I haven't allocated brain-space.

Maybe its time I did.

Cheers

Mike

[Dimitri Maziuk]

On 10/9/2019 6:40 PM, Mike Dewhirst wrote:

> Dimitri thank you. I had not thought of Docker because I have avoided
> thinking of Docker for years. That means I haven't allocated brain-space.
>
> Maybe its time I did.

With core python being incompatible with itself and its DLL hell on top,
there is no alternative.

Dima

[Jonathan Laufersweiler]

All of these suggested approaches are good in their own way. They differ in where they put the complexity that solves the problem. The right one for a given situation is the one that puts that solution-complexity where it will be the least painful to make work with the rest of your environment. -JL

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/8f80bf41-604b-1dc1-e79d-87f5e219c4fb%40bmrb.wisc.edu.

[Mike Dewhirst]

On 11/10/2019 1:57 am, 'Dimitri Maziuk' via Trac Users wrote:
> With core python being incompatible with itself and its DLL hell on
> top, there is no alternative.

The Trac server will be Ubuntu 18.04 not Windows. Does that modify your
"no alternative."?

As it happens, already running on the target machine is Apache serving
four Django sites and svn. That's why I had to take Trac down.

What does "core python being incompatible with itself" mean?

That's 2 questions - sorry to be a pain.

Thanks

Mike

[Dimitri Maziuk]

On 10/11/2019 2:57 AM, Mike Dewhirst wrote:

> The Trac server will be Ubuntu 18.04 not Windows. Does that modify your
> "no alternative."?

Containers aren't portable, you need a windows container to run on
windows and a linux one to run on linux.

> As it happens, already running on the target machine is Apache serving
> four Django sites and svn. That's why I had to take Trac down.

Simply put, trac webserver is inside the container and is listening on a
port. Host apache is proxying trac url to that port:
ProxyPass /trac/ http://127.0.0.1:9876/

> What does "core python being incompatible with itself" mean?

It means I can still run perl scripts from the 90s. Can't read them, but
they'll run on ubuntu 18.04. Python: not so much.

Dima

[Mike Dewhirst]

On 12/10/2019 3:07 am, 'Dimitri Maziuk' via Trac Users wrote:
> It means I can still run perl scripts from the 90s. Can't read them,
> but they'll run on ubuntu 18.04. Python: not so much.

Very good. I couldn't read the perl I wrote let alone anyone else's.
That's why I'm in python.

[Mike Dewhirst]

Thank you Dima. Much appreciated.

M