headers
Jani Tiainen | 1 Jul 2008 07:10
Picon

[Trac-dev] Re: User system - some thoughts


Noah Kantrowitz kirjoitti:
> 
> On Jun 30, 2008, at 4:32 AM, Jani Tiainen wrote:
> 
>> As I promised, I've given some thoughts about this user system and I
>> have some visions how it could work. Note that this is now written  
>> based
>> on external experience without looking how Trac internals now work.
>>
>> First at all, user handling would be divided to three different  
>> modules
>> by functionality:
>>
>> 'authentication', 'authorization' and 'profile'.
> 
> So your idea of a "profile" already exists in the guise of session  
> variables. This isn't the problem. There are two major issues with the  
> current user/session system. 1) We have no good way to enumerate valid  
> users. 2) It isn't possible to pull session keys from anywhere other  
> than the database. Both are relatively minor fixes, just need to get  
> around to doing it.

Kind of a yes...

I'm still trying to formalize this all to more comprehensive 
documentation but basically I'm trying to achieve common backend store 
to store and retrieve authentication, authorization and user data from 
virtually anywhere.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rupert.thurner@gmail.com | 1 Jul 2008 12:10
Picon
Gravatar

[Trac-dev] tradadmin: install as zipped egg, or unpacked egg


hi,

when doing a hardware change we noted that tracadmin gets installed as
unzipped egg, contrary to most other eggs and we have to set access
permissions on subdirectories because of this.

why is this, and how could be install it as zipped egg?

# easy_install http://svn.edgewall.com/repos/trac/sandbox/webadmin/
Downloading http://svn.edgewall.com/repos/trac/sandbox/webadmin/
Doing subversion checkout from http://svn.edgewall.com/repos/trac/sandbox/webadmin/
to /tmp/easy_install-Kuru-D/webadmin
Processing webadmin
Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-Kuru-D/
webadmin/egg-dist-tmp-_IP0Tz
zip_safe flag not set; analyzing archive contents...
webadmin.plugin: module references __file__

kr, rupert.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 9 comments |
headers
Alec Thomas | 1 Jul 2008 12:16
Gravatar

[Trac-dev] Re: tradadmin: install as zipped egg, or unpacked egg


This occurs because Trac's static content and templates are shipped
within the egg. They must be accessible for normal file access and
thus the egg must be unpacked, or cracked open, if you like.

2008/7/1 rupert.thurner <at> gmail.com <rupert.thurner <at> gmail.com>:
>
> hi,
>
> when doing a hardware change we noted that tracadmin gets installed as
> unzipped egg, contrary to most other eggs and we have to set access
> permissions on subdirectories because of this.
>
> why is this, and how could be install it as zipped egg?
>
> # easy_install http://svn.edgewall.com/repos/trac/sandbox/webadmin/
> Downloading http://svn.edgewall.com/repos/trac/sandbox/webadmin/
> Doing subversion checkout from http://svn.edgewall.com/repos/trac/sandbox/webadmin/
> to /tmp/easy_install-Kuru-D/webadmin
> Processing webadmin
> Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-Kuru-D/
> webadmin/egg-dist-tmp-_IP0Tz
> zip_safe flag not set; analyzing archive contents...
> webadmin.plugin: module references __file__
>
> kr, rupert.
> >
>

--

--
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jani Tiainen | 1 Jul 2008 12:47
Picon

[Trac-dev] Re: tradadmin: install as zipped egg, or unpacked egg


Alec Thomas kirjoitti:
> This occurs because Trac's static content and templates are shipped
> within the egg. They must be accessible for normal file access and
> thus the egg must be unpacked, or cracked open, if you like.

I don't get it.

Wasn't setuptools meant for using simple .egg files (at least most of my 
plugins are in zipfiles, even they contain shared data) and in runtime 
setuptools extracts plugins (and staticdata) to some temporary directory 
(egg-cache).

So there is something incorrect in above statement.

Actually now that I look my plugins only EGG that is installed as 
extracted is Trac itself for some reason...

Altough that shouldn't be necessary since to get static resources out - 
user is required to run "deploy" command to extract static data from .egg.

Which makes me wonder how system can cope with several trac-admin/tracd 
scripts...

--

-- 
Jani Tiainen

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
(Continue reading)

Permalink | Reply | 7 comments |
headers
Lucas Eisenzimmer | 1 Jul 2008 12:52
Picon

[Trac-dev] Catch formatter.context in convert_content()


I am inquiring some advice although I know that it is a tough time with the
release of 0.11 (although my issue is somehow related with this).

I am conducting some feasibility studies for a TracToDoc (yes, MS Word)
export and have one bigger issue there, which is images. The export works
like e.g. the PDF-Plugin, which is: (1) saving the wiki page into a
temporary file, (2) converting it, (3) reading the converted file and
returning its contents. 
The export of images usually works like that the href-attributes in the
<img>-Tags created by the ImageMacro are replaced using regexps to directly
point to the files itself. There I face a problem. 

The wiki page is being rendered the new way as described in
http://trac.edgewall.org/wiki/WikiMacros#expand_macrodetails. Speaking of
the context, the formatter object is not available, since for conversions
the IContentConverter interface is used (instead of the IWikiMacroProvider).
The according convert_content() method still provides me with the req object
(instead of the formatter one). I retrieved the context using
Context.from_request(req), but by doing this, the ImageMacro fails with an
permission issue (attached below). My guess is that, as described in
http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11#IWikiMacroProvider,
the context created by Context.from_request(req) is different to
formatter.context. The same error occurs with the PDF-Plugin, where images
worked until I updated Trac from 0.11b2 to 0.11rc1. Is this the crux of the
matter? The image is an attachment, but with images from svn the same
problem occurs.

So, assuming I have to use formatter.context instead of
Context.from_request(req), my question basically is: how can I get hold of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joachim Hoessler | 1 Jul 2008 12:59

[Trac-dev] Re: Trac Plugin development using the Eclipse IDE and PyDev


Jani Tiainen wrote:
> Maybe I'm doing something wrong here... How have you arranged your projects?
> 
> Since I have now two projects, one that is my plugin and second one 
> containing trac sources. and those sources I'm using to run as.

I have basically the same arrangement.

> I can debug my plugin without troubles and files that are in use before 
> httpd starts run...

I experience this behavior (no debugging after httpd starts) only if I 
use the --auto-reload option.

> Oh, and I'm running under Windows, maybe that's the catch?

I'm running windows (XP) as well.

-- Joachim

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
osimons | 1 Jul 2008 13:09
Picon

[Trac-dev] Re: tradadmin: install as zipped egg, or unpacked egg


On Jul 1, 12:47 pm, Jani Tiainen <rede... <at> gmail.com> wrote:
> Alec Thomas kirjoitti:
>
> > This occurs because Trac's static content and templates are shipped
> > within the egg. They must be accessible for normal file access and
> > thus the egg must be unpacked, or cracked open, if you like.
>
> I don't get it.
>
> Wasn't setuptools meant for using simple .egg files (at least most of my
> plugins are in zipfiles, even they contain shared data) and in runtime
> setuptools extracts plugins (and staticdata) to some temporary directory
> (egg-cache).
>
> So there is something incorrect in above statement.
>
> Actually now that I look my plugins only EGG that is installed as
> extracted is Trac itself for some reason...

Trac setup.py uses the zip_safe = False flag to ask setuptools to
extract when installing.

>
> Altough that shouldn't be necessary since to get static resources out -
> user is required to run "deploy" command to extract static data from .egg.

Templates are also static resources that need to be accessed - they
don't get 'deployed'.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jani Tiainen | 1 Jul 2008 13:36
Picon

[Trac-dev] Re: tradadmin: install as zipped egg, or unpacked egg


osimons kirjoitti:
> 
> On Jul 1, 12:47 pm, Jani Tiainen <rede... <at> gmail.com> wrote:
>> Alec Thomas kirjoitti:
>>
>>> This occurs because Trac's static content and templates are shipped
>>> within the egg. They must be accessible for normal file access and
>>> thus the egg must be unpacked, or cracked open, if you like.
>> I don't get it.
>>
>> Wasn't setuptools meant for using simple .egg files (at least most of my
>> plugins are in zipfiles, even they contain shared data) and in runtime
>> setuptools extracts plugins (and staticdata) to some temporary directory
>> (egg-cache).
>>
>> So there is something incorrect in above statement.
>>
>> Actually now that I look my plugins only EGG that is installed as
>> extracted is Trac itself for some reason...
> 
> Trac setup.py uses the zip_safe = False flag to ask setuptools to
> extract when installing.
> 
>> Altough that shouldn't be necessary since to get static resources out -
>> user is required to run "deploy" command to extract static data from .egg.
> 
> Templates are also static resources that need to be accessed - they
> don't get 'deployed'.
(Continue reading)

Permalink | Reply | 4 comments |
headers
osimons | 1 Jul 2008 13:55
Picon

[Trac-dev] Re: tradadmin: install as zipped egg, or unpacked egg


On Jul 1, 1:36 pm, Jani Tiainen <rede... <at> gmail.com> wrote:
> osimons kirjoitti:
>
> > On Jul 1, 12:47 pm, Jani Tiainen <rede... <at> gmail.com> wrote:
> >> Alec Thomas kirjoitti:
>
> >>> This occurs because Trac's static content and templates are shipped
> >>> within the egg. They must be accessible for normal file access and
> >>> thus the egg must be unpacked, or cracked open, if you like.
> >> I don't get it.
>
> >> Wasn't setuptools meant for using simple .egg files (at least most of my
> >> plugins are in zipfiles, even they contain shared data) and in runtime
> >> setuptools extracts plugins (and staticdata) to some temporary directory
> >> (egg-cache).
>
> >> So there is something incorrect in above statement.
>
> >> Actually now that I look my plugins only EGG that is installed as
> >> extracted is Trac itself for some reason...
>
> > Trac setup.py uses the zip_safe = False flag to ask setuptools to
> > extract when installing.
>
> >> Altough that shouldn't be necessary since to get static resources out -
> >> user is required to run "deploy" command to extract static data from .egg.
>
> > Templates are also static resources that need to be accessed - they
> > don't get 'deployed'.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Noah Kantrowitz | 1 Jul 2008 14:18
Gravatar

[Trac-dev] Re: tradadmin: install as zipped egg, or unpacked egg


On Jul 1, 2008, at 6:47 AM, Jani Tiainen wrote:

>
> Alec Thomas kirjoitti:
>> This occurs because Trac's static content and templates are shipped
>> within the egg. They must be accessible for normal file access and
>> thus the egg must be unpacked, or cracked open, if you like.
>
> I don't get it.
>
> Wasn't setuptools meant for using simple .egg files (at least most  
> of my
> plugins are in zipfiles, even they contain shared data) and in runtime
> setuptools extracts plugins (and staticdata) to some temporary  
> directory
> (egg-cache).

Yes, however this is 1) slower and 2) more likely to result in the  
famous PYTHON_EGG_CACHE errors. It is tricky to make sure the egg  
cache variable gets set correctly, as seen by the current issues with  
zipped eggs and Genshi, so this just side steps the problem for now.  
If you aren't using mod_python you could probably remove  
zip_safe=False with no ill effects.

>
>
> So there is something incorrect in above statement.
>
> Actually now that I look my plugins only EGG that is installed as
(Continue reading)

Permalink | Reply | 0 comments |

Gmane