Mailing List Archive

Component <Component trac.db.api.DatabaseManager> failed with TracError: Unsupported database type "postgres" after re-running trac-admin deploy
I have a Trac instance that I've had running happily on postgresql for a
week or so now.

I have installed the PdfPreviewPlugin
<https://trac-hacks.org/wiki/PdfPreviewPlugin> but couldn't get it to
work. I went hunting through the plugin's bug list and found this one
<https://trac-hacks.org/ticket/13746> which indicated that I needed to run *trac-admin
deploy* after installing (no mention of this in the installation
instructions!)

After running *trac-admin /path/to/my/trac/instance deploy
/path/to/web/root* and then restarting apache, my site is now completely
broken, simply displaying:

Trac Error
TracError: Unable to check for upgrade of trac.db.api.DatabaseManager:
TracError: Unsupported database type "postgres"

on the home page or any other URL within my site.

I'm mystified as to why doing a trac-admin deploy would even cause the
db-connection to break, let alone how. Google hasn't provided any
enlightenment so far.

In the log, in addition to the above messages I see:
2021-01-02 16:51:05,224 Trac[loader] DEBUG: Loading plugin
"trac.db.postgres" from "/<some folders>/.local/lib/python2.7/site-packages"
2021-01-02 16:51:05,224 Trac[loader] DEBUG: Skipping "trac.db.postgres =
trac.db.postgres_backend": DistributionNotFound: ('psycopg2>=2.0 or
psycopg2-binary', [
'Trac'])

If I check my ~/.local/lib/python2.7/site-packages folders I don't see any
evidence of psycopg2, but if I enter the virtuanenv my server is running in
and try and install psycopg2 it says it's already installed. Similarly if
I run python and run "import psycopg2" that executes without any error.

Any suggestions will be most welcome!

Cheers,

Rob Hills
Waikiki, Western Australia

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/04dcc0f9-e6af-447c-a88c-2e5f0e1471cdn%40googlegroups.com.
Re: Component <Component trac.db.api.DatabaseManager> failed with TracError: Unsupported database type "postgres" after re-running trac-admin deploy [ In reply to ]
On Saturday, January 2, 2021 at 1:32:39 AM UTC-8 rcp....@gmail.com wrote:

>
> I have a Trac instance that I've had running happily on postgresql for a
> week or so now.
>
> I have installed the PdfPreviewPlugin
> <https://trac-hacks.org/wiki/PdfPreviewPlugin> but couldn't get it to
> work. I went hunting through the plugin's bug list and found this one
> <https://trac-hacks.org/ticket/13746> which indicated that I needed to
> run *trac-admin deploy* after installing (no mention of this in the
> installation instructions!)
>

It's only necessary to run deploy if you have mapped static resources for
your webserver, which is a performance optimization:
https://trac-hacks.org/wiki/TracPlugins#Redeployingstaticresources

It's very tedious to maintain install instructions for all of the plugins,
so we put a generic statement here and hope that users will familiarize
with the TracPlugin page:
https://trac-hacks.org/wiki/PdfPreviewPlugin#Installation

It's still fairly complex and I've been thinking for a long time about how
to simplify things so that a new or casual user doesn't need to understand
so many details.


> After running *trac-admin /path/to/my/trac/instance deploy
> /path/to/web/root* and then restarting apache, my site is now completely
> broken, simply displaying:
>
> Trac Error
> TracError: Unable to check for upgrade of trac.db.api.DatabaseManager:
> TracError: Unsupported database type "postgres"
>
> on the home page or any other URL within my site.
>
> I'm mystified as to why doing a trac-admin deploy would even cause the
> db-connection to break, let alone how. Google hasn't provided any
> enlightenment so far.
>
> In the log, in addition to the above messages I see:
> 2021-01-02 16:51:05,224 Trac[loader] DEBUG: Loading plugin
> "trac.db.postgres" from "/<some folders>/.local/lib/python2.7/site-packages"
> 2021-01-02 16:51:05,224 Trac[loader] DEBUG: Skipping "trac.db.postgres =
> trac.db.postgres_backend": DistributionNotFound: ('psycopg2>=2.0 or
> psycopg2-binary', [
> 'Trac'])
>
> If I check my ~/.local/lib/python2.7/site-packages folders I don't see any
> evidence of psycopg2, but if I enter the virtuanenv my server is running in
> and try and install psycopg2 it says it's already installed. Similarly if
> I run python and run "import psycopg2" that executes without any error.
>
> Any suggestions will be most welcome!
>

The deploy command rewrites trac.wsgi, so your customizations were likely
overwritten.
https://groups.google.com/g/trac-users/c/Jm9JbiG5BJg/m/C8i9vPSTBgAJ

"#!/<various-folders>/applications/trac/venv/bin/python" has likely been
replaced with the path to the default python.

As a workaround, I'd add a "deploy.sh" that runs deploy then copies your
trac.wsgi to the deploy path. I suppose we should add an option to the
deploy command to only extract static resources and not the webserver
scripts.
https://trac.edgewall.org/ticket/9331

Ryan

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/671ca738-6554-4851-8767-a34e46c9a7b3n%40googlegroups.com.
Re: Component <Component trac.db.api.DatabaseManager> failed with TracError: Unsupported database type "postgres" after re-running trac-admin deploy [ In reply to ]
Thanks Ryan,

I'd checked trac.wsgi initially as that was my first thought. However, it
was actually pointing at the correct Python in the first line so I made the
silly mistake of assuming that Deploy had NOT overwritten my trac.wsgi. As
it happens it had, blowing away my customisations further down the script
to work around the bug in passenger - wsgi as well as other changes
obviously necessary to get Trac to work in a Virtual Environment in my
Centos 7 + WHM + cPanel setup.

Regarding the deploy command replacing customised wsgi scripts (and
presumably the other trac.*gi scripts in the cgi-bin directory) how much
effort would be involved in comparing the new scripts with existing ones
and alerting the user if there is a change? To partly answer my own
question, I hunted through the Trac code and found the relevant code here
<https://trac.edgewall.org/browser/trunk/trac/env.py#L993>. As someone
with only a very superficial understanding of how Trac works and with a
limited knowledge of Python I'd have thought it wouldn't be too difficult
to tweak the code to manage the situation where there is a change to one of
these two scripts.

If you think it's worth considering, I'm happy to add a ticket describing a
proposed workflow and perhaps even have a go at submitting a patch.

On Sunday, 3 January 2021 at 03:33:43 UTC+8 RjOllos wrote:

> On Saturday, January 2, 2021 at 1:32:39 AM UTC-8 rcp....@gmail.com wrote:
>
>>
>> I have a Trac instance that I've had running happily on postgresql for a
>> week or so now.
>>
>> I have installed the PdfPreviewPlugin
>> <https://trac-hacks.org/wiki/PdfPreviewPlugin> but couldn't get it to
>> work. I went hunting through the plugin's bug list and found this one
>> <https://trac-hacks.org/ticket/13746> which indicated that I needed to
>> run *trac-admin deploy* after installing (no mention of this in the
>> installation instructions!)
>>
>
> It's only necessary to run deploy if you have mapped static resources for
> your webserver, which is a performance optimization:
> https://trac-hacks.org/wiki/TracPlugins#Redeployingstaticresources
>
> It's very tedious to maintain install instructions for all of the plugins,
> so we put a generic statement here and hope that users will familiarize
> with the TracPlugin page:
> https://trac-hacks.org/wiki/PdfPreviewPlugin#Installation
>
> It's still fairly complex and I've been thinking for a long time about how
> to simplify things so that a new or casual user doesn't need to understand
> so many details.
>
>
>> After running *trac-admin /path/to/my/trac/instance deploy
>> /path/to/web/root* and then restarting apache, my site is now completely
>> broken, simply displaying:
>>
>> Trac Error
>> TracError: Unable to check for upgrade of trac.db.api.DatabaseManager:
>> TracError: Unsupported database type "postgres"
>>
>> on the home page or any other URL within my site.
>>
>> I'm mystified as to why doing a trac-admin deploy would even cause the
>> db-connection to break, let alone how. Google hasn't provided any
>> enlightenment so far.
>>
>> In the log, in addition to the above messages I see:
>> 2021-01-02 16:51:05,224 Trac[loader] DEBUG: Loading plugin
>> "trac.db.postgres" from "/<some folders>/.local/lib/python2.7/site-packages"
>> 2021-01-02 16:51:05,224 Trac[loader] DEBUG: Skipping "trac.db.postgres =
>> trac.db.postgres_backend": DistributionNotFound: ('psycopg2>=2.0 or
>> psycopg2-binary', [
>> 'Trac'])
>>
>> If I check my ~/.local/lib/python2.7/site-packages folders I don't see
>> any evidence of psycopg2, but if I enter the virtuanenv my server is
>> running in and try and install psycopg2 it says it's already installed.
>> Similarly if I run python and run "import psycopg2" that executes without
>> any error.
>>
>> Any suggestions will be most welcome!
>>
>
> The deploy command rewrites trac.wsgi, so your customizations were likely
> overwritten.
> https://groups.google.com/g/trac-users/c/Jm9JbiG5BJg/m/C8i9vPSTBgAJ
>
> "#!/<various-folders>/applications/trac/venv/bin/python" has likely been
> replaced with the path to the default python.
>
> As a workaround, I'd add a "deploy.sh" that runs deploy then copies your
> trac.wsgi to the deploy path. I suppose we should add an option to the
> deploy command to only extract static resources and not the webserver
> scripts.
> https://trac.edgewall.org/ticket/9331
>
> Ryan
>

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/e8b2131f-98e6-4d21-80ba-05c48facc262n%40googlegroups.com.
Re: Component <Component trac.db.api.DatabaseManager> failed with TracError: Unsupported database type "postgres" after re-running trac-admin deploy [ In reply to ]
On Saturday, January 2, 2021 at 6:11:21 PM UTC-8 rcp....@gmail.com wrote:

> Thanks Ryan,
>
> I'd checked trac.wsgi initially as that was my first thought. However, it
> was actually pointing at the correct Python in the first line so I made the
> silly mistake of assuming that Deploy had NOT overwritten my trac.wsgi. As
> it happens it had, blowing away my customisations further down the script
> to work around the bug in passenger - wsgi as well as other changes
> obviously necessary to get Trac to work in a Virtual Environment in my
> Centos 7 + WHM + cPanel setup.
>
> Regarding the deploy command replacing customised wsgi scripts (and
> presumably the other trac.*gi scripts in the cgi-bin directory) how much
> effort would be involved in comparing the new scripts with existing ones
> and alerting the user if there is a change? To partly answer my own
> question, I hunted through the Trac code and found the relevant code here
> <https://trac.edgewall.org/browser/trunk/trac/env.py#L993>. As someone
> with only a very superficial understanding of how Trac works and with a
> limited knowledge of Python I'd have thought it wouldn't be too difficult
> to tweak the code to manage the situation where there is a change to one of
> these two scripts.
>
> If you think it's worth considering, I'm happy to add a ticket describing
> a proposed workflow and perhaps even have a go at submitting a patch.
>

I would like to do something to address this situation, but it would seem
to be more straightforward to either add a switch to the deploy command for
"htdocs only", or add a "redeploy" command that extracts htdocs but doesn't
touch cgi-bin.

Ryan

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/28385fed-2920-435a-91f8-0797a4943ed1n%40googlegroups.com.
Re: Component <Component trac.db.api.DatabaseManager> failed with TracError: Unsupported database type "postgres" after re-running trac-admin deploy [ In reply to ]
Yes, I agree, a "redeploy" command would work perfectly and ought to be
pretty simple to code I'd have thought.

On Monday, 4 January 2021 at 09:30:30 UTC+8 RjOllos wrote:

> On Saturday, January 2, 2021 at 6:11:21 PM UTC-8 rcp....@gmail.com wrote:
>
>> Thanks Ryan,
>>
>> I'd checked trac.wsgi initially as that was my first thought. However,
>> it was actually pointing at the correct Python in the first line so I made
>> the silly mistake of assuming that Deploy had NOT overwritten my
>> trac.wsgi. As it happens it had, blowing away my customisations further
>> down the script to work around the bug in passenger - wsgi as well as other
>> changes obviously necessary to get Trac to work in a Virtual Environment in
>> my Centos 7 + WHM + cPanel setup.
>>
>> Regarding the deploy command replacing customised wsgi scripts (and
>> presumably the other trac.*gi scripts in the cgi-bin directory) how much
>> effort would be involved in comparing the new scripts with existing ones
>> and alerting the user if there is a change? To partly answer my own
>> question, I hunted through the Trac code and found the relevant code here
>> <https://trac.edgewall.org/browser/trunk/trac/env.py#L993>. As someone
>> with only a very superficial understanding of how Trac works and with a
>> limited knowledge of Python I'd have thought it wouldn't be too difficult
>> to tweak the code to manage the situation where there is a change to one of
>> these two scripts.
>>
>> If you think it's worth considering, I'm happy to add a ticket describing
>> a proposed workflow and perhaps even have a go at submitting a patch.
>>
>
> I would like to do something to address this situation, but it would seem
> to be more straightforward to either add a switch to the deploy command for
> "htdocs only", or add a "redeploy" command that extracts htdocs but doesn't
> touch cgi-bin.
>
> Ryan
>

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/56b11a51-9078-4bb1-9bcd-245c4352bbcfn%40googlegroups.com.