Forgot to include the error message in my previous post:
Traceback (most recent call last):
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core\servers
\basehttp.py", line 277, in run
self.result = application(self.environ, self.start_response)
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core\servers
\basehttp.py", line 634, in __call__
return self.application(environ, start_response)
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core\handlers
\wsgi.py", line 220, in __call__
response = middleware_method(request, response)
File "C:\Soft\Dev_soft\Libs\Python\Django\apps\django-hotclub\trunk
\apps\djangologging\middleware.py", line 153, in process_response
self._rewrite_html(request, response)
File "C:\Soft\Dev_soft\Libs\Python\Django\apps\django-hotclub\trunk
\apps\djangologging\middleware.py", line 187, in _rewrite_html
response.content = close_body_re.sub(r'%s\1' % footer,
response.content)
File "C:\Python25\Lib\re.py", line 269, in _subx
template = _compile_repl(template, pattern)
File "C:\Python25\Lib\re.py", line 256, in _compile_repl
raise error, v # invalid expression
error: bad group name
On Aug 14, 10:16 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
Also if anyone running pinux successfully with django trunk version,
let me know the exact revision number you are using so that I can play
with the apps provided by pinux without diving into fixing cores of
pinux to be compatible with current django trunk.
Seems like a bug in django, please wait a couple of hours (or
minutes?) and do a svn up, or do a svn up -r8339 in the meantime.
Django trunk is very unstable right now as the feature freeze is
aproaching. After tomorrow you would probably not have to deal with
this kind of issues.
I have not been able to reproduce the problem described. I dont see
any changes to django_logging (which is where the re error is from and
is not actually directly related to any django code).
I have been continually updating and running pinax for the past 24
hours and have not had any problems.
> Hi Ariel,
> Thanx for your reply. I understand the fact & decided to wait till
> tomorrow to get the feature freeze release.
> Thanks again.
> Shihan
After updating django trunk to r8375 which is currently in 1.0 beta1
phase and should be more stable regarding the feature freeze for 1.0,
I'm still getting the same error as given below :
Traceback (most recent call last):
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core\servers
\basehttp.py", line 277, in run
self.result = application(self.environ, self.start_response)
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core\servers
\basehttp.py", line 634, in __call__
return self.application(environ, start_response)
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core\handlers
\wsgi.py", line 220, in __call__
response = middleware_method(request, response)
File "C:\Soft\Dev_soft\Libs\Python\Django\apps\django-hotclub\trunk
\apps\djangologging\middleware.py", line 153, in process_response
self._rewrite_html(request, response)
File "C:\Soft\Dev_soft\Libs\Python\Django\apps\django-hotclub\trunk
\apps\djangologging\middleware.py", line 187, in _rewrite_html
response.content = close_body_re.sub(r'%s\1' % footer,
response.content)
File "C:\Python25\Lib\re.py", line 269, in _subx
template = _compile_repl(template, pattern)
File "C:\Python25\Lib\re.py", line 256, in _compile_repl
raise error, v # invalid expression
error: bad group name
To resolve the issue by my own I tried the followings successively but
all attempts failed :
1. Updated django trunk to its latest revision (8375)
2. Deleted all compile pyc files from both django and django-hotclub
folders.
3. Checked sys.path after running manage.py shell to see whether every
path entries are pointing to the right directories.
Also note that in every attempt I removed the sqlite3 database dev.db
and ran manage.py syncdb before running manage.py runserver to test
the installation.
I've tried also with commenting out the problematic middleware entry
'djangologging.middleware.LoggingMiddleware' from settings.py, and the
previous error disappeared and the httpresponse emitted but with two
new errors (the first is generated only once for the first hit to site
base url and then the second for all hit):
First error:
Request Method: GET
Request URL: http://localhost:8000/ Exception Type: TemplateSyntaxError
Exception Value: Caught an exception while rendering: Could not
import friends_app.views. Error was: No module named
gdata.contacts.service Original Traceback (most recent call last):
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\template
\debug.py", line 71, in render_node result = node.render(context) File
"C:\Soft\Dev_soft\Libs\Python\Django\svn\django\template
\defaulttags.py", line 365, in render return reverse(self.view_name,
args=args, kwargs=kwargs) File "C:\Soft\Dev_soft\Libs\Python\Django\svn
\django\core\urlresolvers.py", line 307, in reverse *args, **kwargs)))
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core
\urlresolvers.py", line 289, in reverse if lookup_view in
self.reverse_dict: File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django
\core\urlresolvers.py", line 225, in _get_reverse_dict for key, value
in pattern.reverse_dict.iteritems(): File "C:\Soft\Dev_soft\Libs\Python
\Django\svn\django\core\urlresolvers.py", line 228, in
_get_reverse_dict self._reverse_dict[pattern.callback] = (pattern,)
File "C:\Soft\Dev_soft\Libs\Python\Django\svn\django\core
\urlresolvers.py", line 188, in _get_callback raise ViewDoesNotExist,
"Could not import %s. Error was: %s" % (mod_name, str(e))
ViewDoesNotExist: Could not import friends_app.views. Error was: No
module named gdata.contacts.service
Exception Location: C:\Soft\Dev_soft\Libs\Python\Django\svn\django
\template\debug.py in render_node, line 81
Python Executable: C:\Python25\python.exe
Python Version: 2.5.2
1. Please, please stop refering to Pinax as Pinux. 2. Please delete all your browsers history and start from fresh database (drop your pg database or erase your dev.db) 3. Delete your pinax checkout and check it out again. (optional) (with svn, not hg or git) 4. Delete your django checkout and check it out again. (optional)
Why am I suggesting all this? Well, in part because the session bug was a really nasty one and it was about sessions in your browser not found on the db. Please clean all your sessions, in browser and db and try again. Steps 3 and 4 are not required (in fact using pinax via svn is) there are a couple of problems with svn:externals linking to branches of some of the apps.
Let me know how it goes. It is a shame you are having so much trouble, but remember: Calm after the storm.
Thanks for your reply. I'm really ashamed to call pinax as pinux all the times. This really a silly mistake and I promise it won't be repeated again.
I've tried all 2,3,4 solution strategies successively as you mentioned, but no luck.
I'm really now feeling frustrating and as the errors are same I'm not replicating again.
PS: Now I'm thinking the issue might be with the Python installation, I'm using Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) and am planning to use other versions as well.
----- Original Message ----- From: Ariel Mauricio Nunez Gomez To: django-hotclub@googlegroups.com Sent: Friday, August 15, 2008 8:27 PM
Subject: Re: Pinux is broken with current django trunk
Sinhan,
1. Please, please stop refering to Pinax as Pinux.
2. Please delete all your browsers history and start from fresh database (drop your pg database or erase your dev.db)
3. Delete your pinax checkout and check it out again. (optional) (with svn, not hg or git)
4. Delete your django checkout and check it out again. (optional)
Why am I suggesting all this? Well, in part because the session bug was a really nasty one and it was about sessions in your browser not found on the db. Please clean all your sessions, in browser and db and try again. Steps 3 and 4 are not required (in fact using pinax via svn is) there are a couple of problems with svn:externals linking to branches of some of the apps.
Let me know how it goes. It is a shame you are having so much trouble, but remember: Calm after the storm.
At last I've fixed the issue with running pinax in windows. I'm
mentioning this as in my understanding any windows user will encounter
the same issue while running pinax and now I am thinking I was the
first pinax user in windows.
The issue was not with pinax instead with a third party library named
gdata on which pinax is dependednt. The gdata package is currently
shipped with two sym-links to the src/gdata and src/atom folders
within the actual site-packages/gdata.py-1.0.13 folder and as windows
does not support sym-linking to other folder as the unix genre OSs,
Pyhton was failing to locate this package. As a resolution I've copied
both the gdata and atom folders from site-packages/gdata.py-1.0.13/src
folder to site-packages/gdata.py-1.0.13 after removing the sym-links
to those folder. I believe somewhere in the pinax document (may be the
README file) this issue should be mentioned so that other windows
users like me won't have this issue.
Also another thing I must note this gdata issue could be fixed with
minimum investigation but it became worst and misleading due to an
issue with django-logging app which failed generically with all
exception pages generated by django. I am thinking to post a ticket
(or may be a patch) on django-logging site so that they update the
middleware code not to intercept the exception pages (as exception
pages have enough info than the logging middleware).
Thanks for your help.
Regards,
Shihan
On Aug 15, 10:16 pm, "M N Islam Shihan" <mnis4...@gmail.com> wrote:
> Thanks for your reply. I'm really ashamed to call pinax as pinux all the times. This really a silly mistake and I promise it won't be repeated again.
> I've tried all 2,3,4 solution strategies successively as you mentioned, but no luck.
> I'm really now feeling frustrating and as the errors are same I'm not replicating again.
> PS: Now I'm thinking the issue might be with the Python installation, I'm using Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) and am planning to use other versions as well.
> Thanks for your help.
> Regards,
> Shihan
> ----- Original Message -----
> From: Ariel Mauricio Nunez Gomez
> To: django-hotclub@googlegroups.com
> Sent: Friday, August 15, 2008 8:27 PM
> Subject: Re: Pinux is broken with current django trunk
> Sinhan,
> 1. Please, please stop refering to Pinax as Pinux.
> 2. Please delete all your browsers history and start from fresh database (drop your pg database or erase your dev.db)
> 3. Delete your pinax checkout and check it out again. (optional) (with svn, not hg or git)
> 4. Delete your django checkout and check it out again. (optional)
> Why am I suggesting all this? Well, in part because the session bug was a really nasty one and it was about sessions in your browser not found on the db. Please clean all your sessions, in browser and db and try again. Steps 3 and 4 are not required (in fact using pinax via svn is) there are a couple of problems with svn:externals linking to branches of some of the apps.
> Let me know how it goes. It is a shame you are having so much trouble, but remember: Calm after the storm.
I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
Rev: 769). Unfortunately for me, replacing the symlinks in gdata
didn't seem to resolve the issue.
I only have about 45 minutes of experience with pinax thus far, so my
problem could definitely be a newbie issue. Any suggestions on how I
can debug this? My stack trace appears below.
Traceback (most recent call last):
File "c:\python25\Lib\site-packages\django\core\servers
\basehttp.py", line 277, in run
self.result = application(self.environ, self.start_response)
File "c:\python25\Lib\site-packages\django\core\servers
\basehttp.py", line 634, in __call__
return self.application(environ, start_response)
File "c:\python25\Lib\site-packages\django\core\handlers\wsgi.py",
line 220, in __call__
response = middleware_method(request, response)
File "C:\Users\allan\src\django\app\pinax\apps\djangologging
\middleware.py", line 153, in process_response
self._rewrite_html(request, response)
File "C:\Users\allan\src\django\app\pinax\apps\djangologging
\middleware.py", line 187, in _rewrite_html
response.content = close_body_re.sub(r'%s\1' % footer,
response.content)
File "c:\python25\lib\re.py", line 261, in _subx
template = _compile_repl(template, pattern)
File "c:\python25\lib\re.py", line 248, in _compile_repl
raise error, v # invalid expression
as a possible solution for django in windows, I think also have some
solution for the sym-links, is the instant django: http://www.instantdjango.com/
And also helps a lot with the testing and development of django, and
also pinax. I have tried it and works fine with the latest version of
pinax and no problem found there.
r
On Aug 17, 4:50 pm, Allan <amet...@mindspring.com> wrote:
> I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> didn't seem to resolve the issue.
> I only have about 45 minutes of experience with pinax thus far, so my
> problem could definitely be a newbie issue. Any suggestions on how I
> can debug this? My stack trace appears below.
> Traceback (most recent call last):
> File "c:\python25\Lib\site-packages\django\core\servers
> \basehttp.py", line 277, in run
> self.result = application(self.environ, self.start_response)
> File "c:\python25\Lib\site-packages\django\core\servers
> \basehttp.py", line 634, in __call__
> return self.application(environ, start_response)
> File "c:\python25\Lib\site-packages\django\core\handlers\wsgi.py",
> line 220, in __call__
> response = middleware_method(request, response)
> File "C:\Users\allan\src\django\app\pinax\apps\djangologging
> \middleware.py", line 153, in process_response
> self._rewrite_html(request, response)
> File "C:\Users\allan\src\django\app\pinax\apps\djangologging
> \middleware.py", line 187, in _rewrite_html
> response.content = close_body_re.sub(r'%s\1' % footer,
> response.content)
> File "c:\python25\lib\re.py", line 261, in _subx
> template = _compile_repl(template, pattern)
> File "c:\python25\lib\re.py", line 248, in _compile_repl
> raise error, v # invalid expression
I'm not sure how instantdjango helped to recover any sym-link related
issues in windows platform. instantdjango is a nice package for
newbies and I used to use instantdjango in my initial days with
django. But when I learned the internals and felt comfortable to do
the details by myself I switched to manual installation of django and
django apps with standalone python-based installation to have greater
flexibilities and controls.
Basically what instantdjango does is just to provide all needed parts
(along with some useful windows tools) along with a utility windows
batch file to set all the necessary python path needed for django
development. I go through and play with the batch file a lot but never
saw anything related to handle sym-links (and its usual as sym-links
are not supported in windows environment, so there should be no native
way in windows batch to deal with unix sym-links).
Anyway, which version of windows you are using with instant-django?
Also are you using manual installation of gdata package using setup.py
into your python_home/lib/site_packages/? Manual installation
shouldn't have the sym-link issue but I liked to avoid it for any
actively developed package checked out from svn repository to stay up-
to-date with recent revisions and utilize the manual update of
pythonpath environment variable. But if you are using the manual
pyhtonpath update strategy like me can you please tell me the revision
number of your gdata package (I think old revisions don't have this
sym-link issue)?
BTW, I'm also a newbie and don't think me otherwise. I am just a bit
curious to know the actual fact that helped you to overcome the gdata
package's sym-link issue in windows platform.
Regards,
Shihan
On Aug 19, 2:51 am, Robin <rober...@gmail.com> wrote:
> as a possible solution for django in windows, I think also have some
> solution for the sym-links, is the instant django:http://www.instantdjango.com/
> And also helps a lot with the testing and development of django, and
> also pinax. I have tried it and works fine with the latest version of
> pinax and no problem found there.
> r
> On Aug 17, 4:50 pm, Allan <amet...@mindspring.com> wrote:
> > I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> > Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> > didn't seem to resolve the issue.
> > I only have about 45 minutes of experience with pinax thus far, so my
> > problem could definitely be a newbie issue. Any suggestions on how I
> > can debug this? My stack trace appears below.
> > Traceback (most recent call last):
> > File "c:\python25\Lib\site-packages\django\core\servers
> > \basehttp.py", line 277, in run
> > self.result = application(self.environ, self.start_response)
> > File "c:\python25\Lib\site-packages\django\core\servers
> > \basehttp.py", line 634, in __call__
> > return self.application(environ, start_response)
> > File "c:\python25\Lib\site-packages\django\core\handlers\wsgi.py",
> > line 220, in __call__
> > response = middleware_method(request, response)
> > File "C:\Users\allan\src\django\app\pinax\apps\djangologging
> > \middleware.py", line 153, in process_response
> > self._rewrite_html(request, response)
1. You can run the "setup.py build" and "setup.py install" commands
from a shell prompt in your django-hotclub/site-packages/
gdata.py-1.0.13 folder or manually update your pythonpath environment
variable to have the full path of the django-hotclub/site-packages/
gdata.py-1.0.13/src folder. Depending on your windows version setting
this variable might vary : but the usual steps to get the environment
variable section is "Control Panel->System->Advanced->Environment
variables"
2. As manage.py in "django-hotclub/pinax" folder set the necessary
python paths, you can try removing anything named "gdata" and "atom"
found in "django-hotclub/site-packages/gdata.py-1.0.13" folder, copy
the contents of "django-hotclub/site-packages/gdata.py-1.0.13/src"
into "django-hotclub/site-packages/gdata.py-1.0.13" folder. If this
doesn't work, open the "packages.pth" file found in "django-hotclub/
trunk/site-packages" using any text editor like notepad++ or editplus
(you shouldn't use notepad as it can't understand unix newline chars)
add any text to that file, save it, remove the added text and save it
again. What you'll do with this can be done very easily in an unix box
using touch command but in windows platform there isn't any native
equivalent.
3. Make sure you ran "manage.py syncdb" command at least once from the
"django-hotclub/pinax" folder.
If the above steps doesn't work for you anyhow, open the settings.py
file "django-hotclub/pinax" folder and comment out the line
'djangologging.middleware.LoggingMiddleware',
in "MIDDLEWARE_CLASSES" configuration by appending a # before that
line to view the actual error that is happening in your browser. You
can also post that response so that we can help you to find out and
resolve the actual issue.
Regards,
Shihan
On Aug 17, 8:50 pm, Allan <amet...@mindspring.com> wrote:
> I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> didn't seem to resolve the issue.
> I only have about 45 minutes of experience with pinax thus far, so my
> problem could definitely be a newbie issue. Any suggestions on how I
> can debug this? My stack trace appears below.
> Traceback (most recent call last):
> File "c:\python25\Lib\site-packages\django\core\servers
> \basehttp.py", line 277, in run
> self.result = application(self.environ, self.start_response)
> File "c:\python25\Lib\site-packages\django\core\servers
> \basehttp.py", line 634, in __call__
> return self.application(environ, start_response)
> File "c:\python25\Lib\site-packages\django\core\handlers\wsgi.py",
> line 220, in __call__
> response = middleware_method(request, response)
> File "C:\Users\allan\src\django\app\pinax\apps\djangologging
> \middleware.py", line 153, in process_response
> self._rewrite_html(request, response)
> File "C:\Users\allan\src\django\app\pinax\apps\djangologging
> \middleware.py", line 187, in _rewrite_html
> response.content = close_body_re.sub(r'%s\1' % footer,
> response.content)
> File "c:\python25\lib\re.py", line 261, in _subx
> template = _compile_repl(template, pattern)
> File "c:\python25\lib\re.py", line 248, in _compile_repl
> raise error, v # invalid expression
don't know exactly why you have problems with pinax and instantdjango
and I haven't. I didn't install anything special (gdata), and don't
make any special sym-link. I am using windows XP. And just grab a
fresh copy of pinax and everything works for me.
Related to the sym-link stuff, I was refering to 'junction' which is
bundled with instantdjango (instantdjango\Utilities\junction.exe) and
is suppose to do the same job as 'ln' on Unix, don't know if this is
usefull to you. Probably you can use this tool to create the proper
links related to gdata lib.
regards, r
On Aug 19, 4:10 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> I'm not sure how instantdjango helped to recover any sym-link related
> issues in windows platform. instantdjango is a nice package for
> newbies and I used to use instantdjango in my initial days with
> django. But when I learned the internals and felt comfortable to do
> the details by myself I switched to manual installation of django and
> django apps with standalone python-based installation to have greater
> flexibilities and controls.
> Basically what instantdjango does is just to provide all needed parts
> (along with some useful windows tools) along with a utility windows
> batch file to set all the necessary python path needed for django
> development. I go through and play with the batch file a lot but never
> saw anything related to handle sym-links (and its usual as sym-links
> are not supported in windows environment, so there should be no native
> way in windows batch to deal with unix sym-links).
> Anyway, which version of windows you are using with instant-django?
> Also are you using manual installation of gdata package using setup.py
> into your python_home/lib/site_packages/? Manual installation
> shouldn't have the sym-link issue but I liked to avoid it for any
> actively developed package checked out from svn repository to stay up-
> to-date with recent revisions and utilize the manual update of
> pythonpath environment variable. But if you are using the manual
> pyhtonpath update strategy like me can you please tell me the revision
> number of your gdata package (I think old revisions don't have this
> sym-link issue)?
> BTW, I'm also a newbie and don't think me otherwise. I am just a bit
> curious to know the actual fact that helped you to overcome the gdata
> package's sym-link issue in windows platform.
> Regards,
> Shihan
> On Aug 19, 2:51 am, Robin <rober...@gmail.com> wrote:
> > Hi !
> > as a possible solution for django in windows, I think also have some
> > solution for the sym-links, is the instant django:http://www.instantdjango.com/
> > And also helps a lot with the testing and development of django, and
> > also pinax. I have tried it and works fine with the latest version of
> > pinax and no problem found there.
> > r
> > On Aug 17, 4:50 pm, Allan <amet...@mindspring.com> wrote:
> > > I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> > > Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> > > didn't seem to resolve the issue.
> > > I only have about 45 minutes of experience with pinax thus far, so my
> > > problem could definitely be a newbie issue. Any suggestions on how I
> > > can debug this? My stack trace appears below.
> > > Traceback (most recent call last):
> > > File "c:\python25\Lib\site-packages\django\core\servers
> > > \basehttp.py", line 277, in run
> > > self.result = application(self.environ, self.start_response)
> > > File "c:\python25\Lib\site-packages\django\core\servers
> > > \basehttp.py", line 634, in __call__
> > > return self.application(environ, start_response)
> > > File "c:\python25\Lib\site-packages\django\core\handlers\wsgi.py",
> > > line 220, in __call__
> > > response = middleware_method(request, response)
> > > File "C:\Users\allan\src\django\app\pinax\apps\djangologging
> > > \middleware.py", line 153, in process_response
> > > self._rewrite_html(request, response)
Surprisingly there isn't any junction.exe in the utilities folder (and
neither in other folders as well) in the instanddjango distribution. I
thought I had a backdated installer and so I've just downloaded the
package again a few while ago but still couldn't found that
junction.exe in current package. Are you using any older version of
instantdjango package which used to include the junction tool (
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx )
provided by system internals, but removed that tool from recent
package anyhow?
But AFAIK, junction.exe can't help to resolve/understand/transform
symlinks created in unix platform to windows equivalent which could
solve this recent gdata symlink issue. I'm not sure how everything is
being special in your environment, but I must congratulate for you to
have a better luck than me.
Anyway, I think this investigation for me to solve this gdata symlink
issue was very useful and I learned quite a few things.
Allan,
Did you find any luck with your pinax installation issue in windows
platform?
I've created a patch for django-hotclub/apps/djangologging/
management.py file so that django logging middleware don't intercept
the exception responses generated by django which is djangologging's
current behaviour and the cause for the misleading exception stack
trace in the browser instead of showing the actual and very useful
exception info generated by django for any exception. I know I need to
place this patch in djangologging's site, but also sharing it here if
anyone needs it while using pinax due to pinax's dependency on
djangologging app. The block next to my signature is the patch code.
+ if isinstance(response,
(Http404,HttpResponseBadRequest,HttpResponseForbidden,HttpResponseNotAllowe d,HttpResponseNotFound,
HttpResponseServerError,)):
+ return response
+
if logging_output_enabled and \
request.META.get('REMOTE_ADDR') in
settings.INTERNAL_IPS and \
not getattr(response, SUPPRESS_OUTPUT_ATTR, False):
On Aug 20, 1:27 am, Robin <rober...@gmail.com> wrote:
> don't know exactly why you have problems with pinax and instantdjango
> and I haven't. I didn't install anything special (gdata), and don't
> make any special sym-link. I am using windows XP. And just grab a
> fresh copy of pinax and everything works for me.
> Related to the sym-link stuff, I was refering to 'junction' which is
> bundled with instantdjango (instantdjango\Utilities\junction.exe) and
> is suppose to do the same job as 'ln' on Unix, don't know if this is
> usefull to you. Probably you can use this tool to create the proper
> links related to gdata lib.
> regards, r
> On Aug 19, 4:10 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> > Hi Robin,
> > I'm not sure how instantdjango helped to recover any sym-link related
> > issues in windows platform. instantdjango is a nice package for
> > newbies and I used to use instantdjango in my initial days with
> > django. But when I learned the internals and felt comfortable to do
> > the details by myself I switched to manual installation of django and
> > django apps with standalone python-based installation to have greater
> > flexibilities and controls.
> > Basically what instantdjango does is just to provide all needed parts
> > (along with some useful windows tools) along with a utility windows
> > batch file to set all the necessary python path needed for django
> > development. I go through and play with the batch file a lot but never
> > saw anything related to handle sym-links (and its usual as sym-links
> > are not supported in windows environment, so there should be no native
> > way in windows batch to deal with unix sym-links).
> > Anyway, which version of windows you are using with instant-django?
> > Also are you using manual installation of gdata package using setup.py
> > into your python_home/lib/site_packages/? Manual installation
> > shouldn't have the sym-link issue but I liked to avoid it for any
> > actively developed package checked out from svn repository to stay up-
> > to-date with recent revisions and utilize the manual update of
> > pythonpath environment variable. But if you are using the manual
> > pyhtonpath update strategy like me can you please tell me the revision
> > number of your gdata package (I think old revisions don't have this
> > sym-link issue)?
> > BTW, I'm also a newbie and don't think me otherwise. I am just a bit
> > curious to know the actual fact that helped you to overcome the gdata
> > package's sym-link issue in windows platform.
> > Regards,
> > Shihan
> > On Aug 19, 2:51 am, Robin <rober...@gmail.com> wrote:
> > > Hi !
> > > as a possible solution for django in windows, I think also have some
> > > solution for the sym-links, is the instant django:http://www.instantdjango.com/
> > > And also helps a lot with the testing and development of django, and
> > > also pinax. I have tried it and works fine with the latest version of
> > > pinax and no problem found there.
> > > r
> > > On Aug 17, 4:50 pm, Allan <amet...@mindspring.com> wrote:
> > > > I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> > > > Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> > > > didn't seem to resolve the issue.
> > > > I only have about 45 minutes of experience with pinax thus far, so my
> > > > problem could definitely be a newbie issue. Any suggestions on how I
> > > > can debug this? My stack trace appears below.
> > > > Traceback (most recent call last):
> > > > File "c:\python25\Lib\site-packages\django\core\servers
> > > > \basehttp.py", line 277, in run
> > > > self.result = application(self.environ, self.start_response)
> Surprisingly there isn't any junction.exe in the utilities folder (and
> neither in other folders as well) in the instanddjango distribution. I
> thought I had a backdated installer and so I've just downloaded the
> package again a few while ago but still couldn't found that
> junction.exe in current package. Are you using any older version of
> instantdjango package which used to include the junction tool (http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx)
> provided by system internals, but removed that tool from recent
> package anyhow?
> But AFAIK, junction.exe can't help to resolve/understand/transform
> symlinks created in unix platform to windows equivalent which could
> solve this recent gdata symlink issue. I'm not sure how everything is
> being special in your environment, but I must congratulate for you to
> have a better luck than me.
> Anyway, I think this investigation for me to solve this gdata symlink
> issue was very useful and I learned quite a few things.
> Allan,
> Did you find any luck with your pinax installation issue in windows
> platform?
> I've created a patch for django-hotclub/apps/djangologging/
> management.py file so that django logging middleware don't intercept
> the exception responses generated by django which is djangologging's
> current behaviour and the cause for the misleading exception stack
> trace in the browser instead of showing the actual and very useful
> exception info generated by django for any exception. I know I need to
> place this patch in djangologging's site, but also sharing it here if
> anyone needs it while using pinax due to pinax's dependency on
> djangologging app. The block next to my signature is the patch code.
> + if isinstance(response,
> (Http404,HttpResponseBadRequest,HttpResponseForbidden,HttpResponseNotAllowe d,HttpResponseNotFound,
> HttpResponseServerError,)):
> + return response
> +
> if logging_output_enabled and \
> request.META.get('REMOTE_ADDR') in
> settings.INTERNAL_IPS and \
> not getattr(response, SUPPRESS_OUTPUT_ATTR, False):
> On Aug 20, 1:27 am, Robin <rober...@gmail.com> wrote:
> > Hello Shihan,
> > don't know exactly why you have problems with pinax and instantdjango
> > and I haven't. I didn't install anything special (gdata), and don't
> > make any special sym-link. I am using windows XP. And just grab a
> > fresh copy of pinax and everything works for me.
> > Related to the sym-link stuff, I was refering to 'junction' which is
> > bundled with instantdjango (instantdjango\Utilities\junction.exe) and
> > is suppose to do the same job as 'ln' on Unix, don't know if this is
> > usefull to you. Probably you can use this tool to create the proper
> > links related to gdata lib.
> > regards, r
> > On Aug 19, 4:10 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> > > Hi Robin,
> > > I'm not sure how instantdjango helped to recover any sym-link related
> > > issues in windows platform. instantdjango is a nice package for
> > > newbies and I used to use instantdjango in my initial days with
> > > django. But when I learned the internals and felt comfortable to do
> > > the details by myself I switched to manual installation of django and
> > > django apps with standalone python-based installation to have greater
> > > flexibilities and controls.
> > > Basically what instantdjango does is just to provide all needed parts
> > > (along with some useful windows tools) along with a utility windows
> > > batch file to set all the necessary python path needed for django
> > > development. I go through and play with the batch file a lot but never
> > > saw anything related to handle sym-links (and its usual as sym-links
> > > are not supported in windows environment, so there should be no native
> > > way in windows batch to deal with unix sym-links).
> > > Anyway, which version of windows you are using with instant-django?
> > > Also are you using manual installation of gdata package using setup.py
> > > into your python_home/lib/site_packages/? Manual installation
> > > shouldn't have the sym-link issue but I liked to avoid it for any
> > > actively developed package checked out from svn repository to stay up-
> > > to-date with recent revisions and utilize the manual update of
> > > pythonpath environment variable. But if you are using the manual
> > > pyhtonpath update strategy like me can you please tell me the revision
> > > number of your gdata package (I think old revisions don't have this
> > > sym-link issue)?
> > > BTW, I'm also a newbie and don't think me otherwise. I am just a bit
> > > curious to know the actual fact that helped you to overcome the gdata
> > > package's sym-link issue in windows platform.
> > > Regards,
> > > Shihan
> > > On Aug 19, 2:51 am, Robin <rober...@gmail.com> wrote:
> > > > Hi !
> > > > as a possible solution for django in windows, I think also have some
> > > > solution for the sym-links, is the instant django:http://www.instantdjango.com/
> > > > And also helps a lot with the testing and development of django, and
> > > > also pinax. I have tried it and works fine with the latest version of
> > > > pinax and no problem found there.
> > > > r
> > > > On Aug 17, 4:50 pm, Allan <amet...@mindspring.com> wrote:
> > > > > I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> > > > > Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> > > > > didn't seem to resolve the issue.
> > > > > I only have about 45 minutes of experience with pinax thus far, so my
> > > > > problem could definitely be a newbie issue. Any suggestions on how I
> > > > > can debug this? My stack trace appears below.
> > > > > Traceback (most recent call last):
> > > > > File "c:\python25\Lib\site-packages\django\core\servers
> > > > > \basehttp.py", line 277, in run
> > > > > self.result = application(self.environ, self.start_response)
As per the issue and patch submission to django-logging site by me,
the author of django-logging app has updated the middleware.py with
the necessary fixes (using much better way than my patch) and
committed the change to r26 in svn repository.
So, updating django-logging app to latest revision should help many
like me and Allan to avoid viewing the exception generated in django-
logging app instead of the actual error response.
Regards,
Shihan
On Aug 20, 9:22 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> On Aug 20, 9:14 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> > Hi Robin,
> > Surprisingly there isn't any junction.exe in the utilities folder (and
> > neither in other folders as well) in the instanddjango distribution. I
> > thought I had a backdated installer and so I've just downloaded the
> > package again a few while ago but still couldn't found that
> > junction.exe in current package. Are you using any older version of
> > instantdjango package which used to include the junction tool (http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx)
> > provided by system internals, but removed that tool from recent
> > package anyhow?
> > But AFAIK, junction.exe can't help to resolve/understand/transform
> > symlinks created in unix platform to windows equivalent which could
> > solve this recent gdata symlink issue. I'm not sure how everything is
> > being special in your environment, but I must congratulate for you to
> > have a better luck than me.
> > Anyway, I think this investigation for me to solve this gdata symlink
> > issue was very useful and I learned quite a few things.
> > Allan,
> > Did you find any luck with your pinax installation issue in windows
> > platform?
> > I've created a patch for django-hotclub/apps/djangologging/
> > management.py file so that django logging middleware don't intercept
> > the exception responses generated by django which is djangologging's
> > current behaviour and the cause for the misleading exception stack
> > trace in the browser instead of showing the actual and very useful
> > exception info generated by django for any exception. I know I need to
> > place this patch in djangologging's site, but also sharing it here if
> > anyone needs it while using pinax due to pinax's dependency on
> > djangologging app. The block next to my signature is the patch code.
> > + if isinstance(response,
> > (Http404,HttpResponseBadRequest,HttpResponseForbidden,HttpResponseNotAllowe d,HttpResponseNotFound,
> > HttpResponseServerError,)):
> > + return response
> > +
> > if logging_output_enabled and \
> > request.META.get('REMOTE_ADDR') in
> > settings.INTERNAL_IPS and \
> > not getattr(response, SUPPRESS_OUTPUT_ATTR, False):
> > On Aug 20, 1:27 am, Robin <rober...@gmail.com> wrote:
> > > Hello Shihan,
> > > don't know exactly why you have problems with pinax and instantdjango
> > > and I haven't. I didn't install anything special (gdata), and don't
> > > make any special sym-link. I am using windows XP. And just grab a
> > > fresh copy of pinax and everything works for me.
> > > Related to the sym-link stuff, I was refering to 'junction' which is
> > > bundled with instantdjango (instantdjango\Utilities\junction.exe) and
> > > is suppose to do the same job as 'ln' on Unix, don't know if this is
> > > usefull to you. Probably you can use this tool to create the proper
> > > links related to gdata lib.
> > > regards, r
> > > On Aug 19, 4:10 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> > > > Hi Robin,
> > > > I'm not sure how instantdjango helped to recover any sym-link related
> > > > issues in windows platform. instantdjango is a nice package for
> > > > newbies and I used to use instantdjango in my initial days with
> > > > django. But when I learned the internals and felt comfortable to do
> > > > the details by myself I switched to manual installation of django and
> > > > django apps with standalone python-based installation to have greater
> > > > flexibilities and controls.
> > > > Basically what instantdjango does is just to provide all needed parts
> > > > (along with some useful windows tools) along with a utility windows
> > > > batch file to set all the necessary python path needed for django
> > > > development. I go through and play with the batch file a lot but never
> > > > saw anything related to handle sym-links (and its usual as sym-links
> > > > are not supported in windows environment, so there should be no native
> > > > way in windows batch to deal with unix sym-links).
> > > > Anyway, which version of windows you are using with instant-django?
> > > > Also are you using manual installation of gdata package using setup.py
> > > > into your python_home/lib/site_packages/? Manual installation
> > > > shouldn't have the sym-link issue but I liked to avoid it for any
> > > > actively developed package checked out from svn repository to stay up-
> > > > to-date with recent revisions and utilize the manual update of
> > > > pythonpath environment variable. But if you are using the manual
> > > > pyhtonpath update strategy like me can you please tell me the revision
> > > > number of your gdata package (I think old revisions don't have this
> > > > sym-link issue)?
> > > > BTW, I'm also a newbie and don't think me otherwise. I am just a bit
> > > > curious to know the actual fact that helped you to overcome the gdata
> > > > package's sym-link issue in windows platform.
> > > > Regards,
> > > > Shihan
> > > > On Aug 19, 2:51 am, Robin <rober...@gmail.com> wrote:
> > > > > Hi !
> > > > > as a possible solution for django in windows, I think also have some
> > > > > solution for the sym-links, is the instant django:http://www.instantdjango.com/
> > > > > And also helps a lot with the testing and development of django, and
> > > > > also pinax. I have tried it and works fine with the latest version of
> > > > > pinax and no problem found there.
> > > > > r
> > > > > On Aug 17, 4:50 pm, Allan <amet...@mindspring.com> wrote:
> > > > > > I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> > > > > > Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> > > > > > didn't seem to resolve the issue.
> > > > > > I only have about 45 minutes of experience with pinax thus far, so my
> > > > > > problem could definitely be a newbie issue. Any suggestions on how I
> > > > > > can debug this? My stack trace appears below.
> > > > > > Traceback (most recent call last):
> > > > > > File "c:\python25\Lib\site-packages\django\core\servers
> > > > > > \basehttp.py", line 277, in run
> > > > > > self.result = application(self.environ, self.start_response)
Shihan , Thanks for your detailed writeup. I got the Pinax truck on
20080926 and was having problems running it on WinXPPro + Python 2.5.2
+ Django 1.0 final release. I just ran the "setup.py build" and
"setup.py install" commands you have documented and the problems were
resolved. :-)
On Aug 19, 7:33 pm, "M. N. Islam Shihan" <mnis4...@gmail.com> wrote:
> 1. You can run the "setup.py build" and "setup.py install" commands
> from a shell prompt in your django-hotclub/site-packages/
> gdata.py-1.0.13 folder or manually update your pythonpath environment
> variable to have the full path of the django-hotclub/site-packages/
> gdata.py-1.0.13/src folder. Depending on your windows version setting
> this variable might vary : but the usual steps to get the environment
> variable section is "Control Panel->System->Advanced->Environment
> variables"
> 2. As manage.py in "django-hotclub/pinax" folder set the necessary
> python paths, you can try removing anything named "gdata" and "atom"
> found in "django-hotclub/site-packages/gdata.py-1.0.13" folder, copy
> the contents of "django-hotclub/site-packages/gdata.py-1.0.13/src"
> into "django-hotclub/site-packages/gdata.py-1.0.13" folder. If this
> doesn't work, open the "packages.pth" file found in "django-hotclub/
> trunk/site-packages" using any text editor like notepad++ or editplus
> (you shouldn't use notepad as it can't understand unix newline chars)
> add any text to that file, save it, remove the added text and save it
> again. What you'll do with this can be done very easily in an unix box
> using touch command but in windows platform there isn't any native
> equivalent.
> 3. Make sure you ran "manage.py syncdb" command at least once from the
> "django-hotclub/pinax" folder.
> If the above steps doesn't work for you anyhow, open the settings.py
> file "django-hotclub/pinax" folder and comment out the line
> 'djangologging.middleware.LoggingMiddleware',
> in "MIDDLEWARE_CLASSES" configuration by appending a # before that
> line to view the actual error that is happening in your browser. You
> can also post that response so that we can help you to find out and
> resolve the actual issue.
> Regards,
> Shihan
> On Aug 17, 8:50 pm, Allan <amet...@mindspring.com> wrote:
> > I seem to be having the same issue (Windows, django-1.0-beta-1, pinax
> > Rev: 769). Unfortunately for me, replacing the symlinks in gdata
> > didn't seem to resolve the issue.
> > I only have about 45 minutes of experience with pinax thus far, so my
> > problem could definitely be a newbie issue. Any suggestions on how I
> > can debug this? My stack trace appears below.
> > Traceback (most recent call last):
> > File "c:\python25\Lib\site-packages\django\core\servers
> > \basehttp.py", line 277, in run
> > self.result = application(self.environ, self.start_response)
> > File "c:\python25\Lib\site-packages\django\core\servers
> > \basehttp.py", line 634, in __call__
> > return self.application(environ, start_response)
> > File "c:\python25\Lib\site-packages\django\core\handlers\wsgi.py",
> > line 220, in __call__
> > response = middleware_method(request, response)
> > File "C:\Users\allan\src\django\app\pinax\apps\djangologging
> > \middleware.py", line 153, in process_response
> > self._rewrite_html(request, response)
> At last I've fixed the issue with running pinax in windows. I'm
> mentioning this as in my understanding any windows user will encounter
> the same issue while running pinax and now I am thinking I was the
> first pinax user in windows.
> The issue was not with pinax instead with a third party library named
> gdata on which pinax is dependednt. The gdata package is currently
> shipped with two sym-links to the src/gdata and src/atom folders
> within the actual site-packages/gdata.py-1.0.13 folder and as windows
> does not support sym-linking to other folder as the unix genre OSs,
> Pyhton was failing to locate this package. As a resolution I've copied
> both the gdata and atom folders from site-packages/gdata.py-1.0.13/src
> folder to site-packages/gdata.py-1.0.13 after removing the sym-links
> to those folder. I believe somewhere in the pinax document (may be the
> README file) this issue should be mentioned so that other windows
> users like me won't have this issue.
> Also another thing I must note this gdata issue could be fixed with
> minimum investigation but it became worst and misleading due to an
> issue with django-logging app which failed generically with all
> exception pages generated by django. I am thinking to post a ticket
> (or may be a patch) on django-logging site so that they update the
> middleware code not to intercept the exception pages (as exception
> pages have enough info than the logging middleware).
> Thanks for your help.
> Regards,
> Shihan
> On Aug 15, 10:16 pm, "M N Islam Shihan" <mnis4...@gmail.com> wrote:
> > Hi Ariel,
> > Thanks for your reply. I'm really ashamed to call pinax as pinux all the times. This really a silly mistake and I promise it won't be repeated again.
> > I've tried all 2,3,4 solution strategies successively as you mentioned, but no luck.
> > I'm really now feeling frustrating and as the errors are same I'm not replicating again.
> > PS: Now I'm thinking the issue might be with the Python installation, I'm using Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) and am planning to use other versions as well.
> > Thanks for your help.
> > Regards,
> > Shihan
> > ----- Original Message -----
> > From: Ariel Mauricio Nunez Gomez
> > To: django-hotclub@googlegroups.com
> > Sent: Friday, August 15, 2008 8:27 PM
> > Subject: Re: Pinux is broken with current django trunk
> > Sinhan,
> > 1. Please, please stop refering to Pinax as Pinux.
> > 2. Please delete all your browsers history and start from fresh database (drop your pg database or erase your dev.db)
> > 3. Delete your pinax checkout and check it out again. (optional) (with svn, not hg or git)
> > 4. Delete your django checkout and check it out again. (optional)
> > Why am I suggesting all this? Well, in part because the session bug was a really nasty one and it was about sessions in your browser not found on the db. Please clean all your sessions, in browser and db and try again. Steps 3 and 4 are not required (in fact using pinax via svn is) there are a couple of problems with svn:externals linking to branches of some of the apps.
> > Let me know how it goes. It is a shame you are having so much trouble, but remember: Calm after the storm.
> At last I've fixed the issue with running pinax in windows. I'm
> mentioning this as in my understanding any windows user will encounter
> the same issue while running pinax and now I am thinking I was the
> first pinax user in windows.
> The issue was not with pinax instead with a third party library named
> gdata on which pinax is dependednt. The gdata package is currently
> shipped with two sym-links to the src/gdata and src/atom folders
> within the actual site-packages/gdata.py-1.0.13 folder and as windows
> does not support sym-linking to other folder as the unix genre OSs,
> Pyhton was failing to locate this package. As a resolution I've copied
> both the gdata and atom folders from site-packages/gdata.py-1.0.13/src
> folder to site-packages/gdata.py-1.0.13 after removing the sym-links
> to those folder. I believe somewhere in the pinax document (may be the
> README file) this issue should be mentioned so that other windows
> users like me won't have this issue.
> Also another thing I must note this gdata issue could be fixed with
> minimum investigation but it became worst and misleading due to an
> issue with django-logging app which failed generically with all
> exception pages generated by django. I am thinking to post a ticket
> (or may be a patch) on django-logging site so that they update the
> middleware code not to intercept the exception pages (as exception
> pages have enough info than the logging middleware).
> Thanks for your help.
> Regards,
> Shihan
> On Aug 15, 10:16 pm, "M N Islam Shihan" <mnis4...@gmail.com> wrote:
> > Hi Ariel,
> > Thanks for your reply. I'm really ashamed to call pinax as pinux all the times. This really a silly mistake and I promise it won't be repeated again.
> > I've tried all 2,3,4 solution strategies successively as you mentioned, but no luck.
> > I'm really now feeling frustrating and as the errors are same I'm not replicating again.
> > PS: Now I'm thinking the issue might be with the Python installation, I'm using Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) and am planning to use other versions as well.
> > Thanks for your help.
> > Regards,
> > Shihan
> > ----- Original Message -----
> > From: Ariel Mauricio Nunez Gomez
> > To: django-hotclub@googlegroups.com
> > Sent: Friday, August 15, 2008 8:27 PM
> > Subject: Re: Pinux is broken with current django trunk
> > Sinhan,
> > 1. Please, please stop refering to Pinax as Pinux.
> > 2. Please delete all your browsers history and start from fresh database (drop your pg database or erase your dev.db)
> > 3. Delete your pinax checkout and check it out again. (optional) (with svn, not hg or git)
> > 4. Delete your django checkout and check it out again. (optional)
> > Why am I suggesting all this? Well, in part because the session bug was a really nasty one and it was about sessions in your browser not found on the db. Please clean all your sessions, in browser and db and try again. Steps 3 and 4 are not required (in fact using pinax via svn is) there are a couple of problems with svn:externals linking to branches of some of the apps.
> > Let me know how it goes. It is a shame you are having so much trouble, but remember: Calm after the storm.
