[Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn -- Some packages may not be found!
Roger Ineichen napsal(a): Hi David Betreff: [Zope-dev] Annoying: Download error: unknown url type: svn -- Some packages may not be found! Which package is emitting the Download error: unknown url type: svn -- Some packages may not be found! Its quite annoying and I have been seeing it crop up in a few builds. Anyone else seeing this. Many thanks. I see this too. Try the buildout debug option, probably this will you give a better output. I have got the same error today. buildout - was not sufficient so I added print output to setuptools/package_index.py and discovered this message is caused by z3c.form: Getting required 'z3c.form' required by plone.z3cform 0.1b2. Reading http://pypi.python.org/simple/z3c.form/ Reading svn://svn.zope.org/repos/main/z3c.form Download error: unknown url type: svn -- Some packages may not be found! Reading http://svn.zope.org/z3c.form We have the best distribution that satisfies 'z3c.form'. Adding find link 'http://download.zope.org/distribution' from z3c.form 1.8.2 Picked: z3c.form = 1.8.2 -- Radim Novotny ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn -- Some packages may not be found!
Radim Novotny, on 2008-05-07: Roger Ineichen napsal(a): Hi David Betreff: [Zope-dev] Annoying: Download error: unknown url type: svn -- Some packages may not be found! Which package is emitting the Download error: unknown url type: svn -- Some packages may not be found! Its quite annoying and I have been seeing it crop up in a few builds. Anyone else seeing this. Many thanks. I see this too. Try the buildout debug option, probably this will you give a better output. I have got the same error today. buildout - was not sufficient so I added print output to setuptools/package_index.py and discovered this message is caused by z3c.form: The same happens for lovely.recipe: http://pypi.python.org/simple/lovely.recipe What is considered to be good practice here? For example this is in the setup.py of grokproject: url='https://launchpad.net/grok', download_url='svn://svn.zope.org/repos/main/grokproject/trunk#egg=grokproject-dev', Looking at the simple cheese shop page: http://pypi.python.org/simple/grokproject I see that the home page url for all released versions is the launchpad url which is probably fine. But the download url is also the same for every release that I checked, namely the trunk#egg, which does not look like a good idea. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ This is your day, don't let them take it away. [Barlow Girl] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] Re: New i18n locale extraction concept
Hi Maurits Betreff: [Zope-dev] Re: New i18n locale extraction concept Christian Zagrodnick, on 2008-05-01: On 2008-05-01 02:06:17 +0200, Roger Ineichen [EMAIL PROTECTED] said: What does this mean? The locale extraction is now a part of a recipe and not a part of a package itself. My goal is to remove the dependencies in the z3c.recipe.i18n, because right now it uses the base implementation in zope.app.locales which makes it depend on the hole zope namepsace. Because of the overall zope.* dependenc in zope.app.locale. Actually, there is lovely.receipe:i18n which provides i18n extraction. Does z3c.recipe.i18n something else or why is there yet another i18n recipe? For me a downside of lovely.recipe:i18n is that it has too many dependencies: the whole of zope. When easy installing it in a virtual env, you end up with 44 MB of eggs. For comparison, easy installing i18ndude needs about 6 MB. Yes, that's what I was asking for. The zope.app.locales has dependencies to each i18n aware zope.* package because it offers transalation for this packages. And at the same time it offers the i18nextract.py script which could be used by other projects. This ends in having dependencies to all zope.* packages. We need to split the locale extraction concept and the concret zope.* package extraction part into two different packages. Then we can reuse the local extraction concept wihtout dependencies to the full zope.* package tree. Regards Roger Ineichen See this (currently) small thread in grok-dev: http://thread.gmane.org/gmane.comp.web.zope.grok.devel/4742 -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ This is your day, don't let them take it away. [Barlow Girl] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Tue May 6 11:00:00 2008 UTC to Wed May 7 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue May 6 21:06:34 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009510.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:08:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009511.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:09:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009512.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:11:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009513.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:12:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009514.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn-- Some packages may not be found!
Hi Betreff: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn-- Some packages may not be found! [...] I have got the same error today. buildout - was not sufficient so I added print output to setuptools/package_index.py and discovered this message is caused by z3c.form: The same happens for lovely.recipe: http://pypi.python.org/simple/lovely.recipe I had no time to take a closer look at that. But I guess it's the lovely.recipe which forces to return the svn-- message. Regards Roger Ineichen What is considered to be good practice here? For example this is in the setup.py of grokproject: url='https://launchpad.net/grok', download_url='svn://svn.zope.org/repos/main/grokproject/trunk# egg=grokproject-dev', Looking at the simple cheese shop page: http://pypi.python.org/simple/grokproject I see that the home page url for all released versions is the launchpad url which is probably fine. But the download url is also the same for every release that I checked, namely the trunk#egg, which does not look like a good idea. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ This is your day, don't let them take it away. [Barlow Girl] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn-- Some packages may not be found!
Hello Roger, Might be, lovely.recipe's pypi page looks like: Author: Lovely Systems office at lovelysystems com Home Page: svn://svn.zope.org/repos/main/lovely.recipe Keywords: buildout recipe filesystem i18n importchecker License: ZPL 2.1 Package Index Owner: batlogg I guess the Home Page makes it crazy. Wednesday, May 7, 2008, 12:45:59 PM, you wrote: RI Hi Betreff: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn-- Some packages may not be found! RI [...] I have got the same error today. buildout - was not sufficient so I added print output to setuptools/package_index.py and discovered this message is caused by z3c.form: The same happens for lovely.recipe: http://pypi.python.org/simple/lovely.recipe RI I had no time to take a closer look at that. But I guess RI it's the lovely.recipe which forces to return the RI svn-- message. RI Regards RI Roger Ineichen What is considered to be good practice here? For example this is in the setup.py of grokproject: url='https://launchpad.net/grok', download_url='svn://svn.zope.org/repos/main/grokproject/trunk# egg=grokproject-dev', Looking at the simple cheese shop page: http://pypi.python.org/simple/grokproject I see that the home page url for all released versions is the launchpad url which is probably fine. But the download url is also the same for every release that I checked, namely the trunk#egg, which does not look like a good idea. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ This is your day, don't let them take it away. [Barlow Girl] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) RI ___ RI Zope-Dev maillist - Zope-Dev@zope.org RI http://mail.zope.org/mailman/listinfo/zope-dev RI ** No cross posts or HTML encoding! ** RI (Related lists - RI http://mail.zope.org/mailman/listinfo/zope-announce RI http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:[EMAIL PROTECTED] -- Quote of the day: People in distress will sometimes prefer a problem that is familiar to a solution that is not. - Neil Postman ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Hi there (especially Christian), I think we can work with explicits saves. In many cases the user won't have to worry about it anyway as the container object will do it for them (besides making the relation), or this 'query container' we spoke of will do it for them (but just the 'save' bit). One point is that the scoped session approach itself doesn't work very well for using multiple databases in the same app. We could consider passing the session along in the containers during object graph wakling (or traversal) so an app can easily traverse into multiple databases. I'm not sure whether we can make the ORM do this for us though; does it initialize the mapping with a session? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Martijn Faassen wrote:
Hi there (especially Christian),
I think we can work with explicits saves. In many cases the user won't
have to worry about it anyway as the container object will do it for
them (besides making the relation), or this 'query container' we spoke
of will do it for them (but just the 'save' bit).
One point is that the scoped session approach itself doesn't work very
well for using multiple databases in the same app. We could consider
passing the session along in the containers during object graph wakling
(or traversal) so an app can easily traverse into multiple databases.
I'm not sure whether we can make the ORM do this for us though; does it
initialize the mapping with a session?
Registering a ScopedSession as a utility seems a good approach. I'm
experimenting with ways of registering engines as local utilities.
Hopefully the combination will allow something along the lines of:
Session =
scoped_session(sessionmaker(bind=LookupEngine('my-engine')...))
provideUtility(Session, IScopedSession, 'my-app')
engine = EngineUtility(url='sqlite:///')
provideUtility(engine, IConnectable, 'my-engine') # but normally a
local utility registration
The code would get a session through:
Session = getUtility(IScopedSession, 'my-app')
session = Session()
Mappers are registered with the metadata, so nothing special need be
done here.
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sqlalchemy
On May 7, 2008, at 7:08 AM, Martijn Faassen wrote: Hi there (especially Christian), I think we can work with explicits saves. In many cases the user won't have to worry about it anyway as the container object will do it for them (besides making the relation), or this 'query container' we spoke of will do it for them (but just the 'save' bit). One point is that the scoped session approach itself doesn't work very well for using multiple databases in the same app. We could consider passing the session along in the containers during object graph wakling (or traversal) so an app can easily traverse into multiple databases. I'm not sure whether we can make the ORM do this for us though; does it initialize the mapping with a session? SQLAlchemy's Session does support multiple engine binds itself, which most easily can be associated with particular mapped classes (i.e. vertical partitioning), so that a single session (or a scoped_session) can read and write data to the appropriate tables transparently (although things like joins across multiple databases will raise errors). Theres a horizontally-partitioning version of Session as well which obviously has a lot more caveats. Using multiple sessions, one per DB is a valid approach as well. I'm not sure if Grok has other things going on when mulitple DBs are in use but SA's multi-bind capability is something to be aware of. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Heads up - package lost on pypi!
Hi all The z3c.configurator package is gone on PyPi. Does sombody know what's happen? And more important, how can we recover this? Regards Roger Ineichen _ END OF MESSAGE ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Hi there, Laurence Rowe wrote: [snip] The code would get a session through: Session = getUtility(IScopedSession, 'my-app') session = Session() The drawback is that this is more typing. You do a utility lookup and an instantiation as opposed to simply importing the scoped session when needed: from myapplication import session session.query(...) One topic we ran into during the megrok.kss discussion is doing multiple instances of the same application, each writing to a different database. You can't hardcode your database name in your application. I think sessions as local utilities would help us solve that problem, right? What would be nice if we could do the 'from myapp import session' pattern and have it use the local utility infrastructure underneath somehow... Possible? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Heads up - package lost on pypi!
Roger Ineichen wrote: Hi all The z3c.configurator package is gone on PyPi. Does sombody know what's happen? And more important, how can we recover this? AFAIK, only owners can delete it. May be deleted by an owner by mistake. I am not sure whether we can recover it. Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Heads up - package lost on pypi!
Baiju M wrote: Roger Ineichen wrote: Hi all The z3c.configurator package is gone on PyPi. Does sombody know what's happen? And more important, how can we recover this? AFAIK, only owners can delete it. May be deleted by an owner by mistake. I am not sure whether we can recover it. Are really sure it ever existed? Googling for: http://pypi.python.org/pypi/z3c.configurator; didnt' return any obvious hits. Doesn't mean much, it might not have made it to the index. Note that there is a z3c.configurator upload here: http://download.zope.org/distribution/ Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] Re: Heads up - package lost on pypi!
Hi Betreff: [Zope-dev] Re: Heads up - package lost on pypi! Baiju M wrote: Roger Ineichen wrote: Hi all The z3c.configurator package is gone on PyPi. Does sombody know what's happen? And more important, how can we recover this? AFAIK, only owners can delete it. May be deleted by an owner by mistake. I am not sure whether we can recover it. Are really sure it ever existed? Googling for: http://pypi.python.org/pypi/z3c.configurator; didnt' return any obvious hits. Doesn't mean much, it might not have made it to the index. Note that there is a z3c.configurator upload here: http://download.zope.org/distribution/ hehe, I guess you are right. Seems that the package never exist on pypi. bad, bad I just uploaded the released 1.1.1 tag version to pypi and will cleanup the setup and release a documented version later. Should I add someone as additional pypi Owner to that package? Regards Roger Ineichen _ END OF MESSAGE Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Martijn Faassen wrote:
Hi there,
Laurence Rowe wrote:
[snip]
The code would get a session through:
Session = getUtility(IScopedSession, 'my-app')
session = Session()
The drawback is that this is more typing. You do a utility lookup and an
instantiation as opposed to simply importing the scoped session when
needed:
from myapplication import session
session.query(...)
One topic we ran into during the megrok.kss discussion is doing multiple
instances of the same application, each writing to a different database.
You can't hardcode your database name in your application. I think
sessions as local utilities would help us solve that problem, right?
What would be nice if we could do the 'from myapp import session'
pattern and have it use the local utility infrastructure underneath
somehow... Possible?
We'll have to stick with scoped sesssions because of threading, but the
engine as local utility pattern should still work.
#myapplication/__init__.py
Session = scoped_session(sessionmaker(bind=LookupEngine('my-engine')...))
engine = EngineUtility(url='sqlite:///')
provideUtility(engine, IConnectable, 'my-engine') # but normally a local
utility registration
#myapplication/foo.py
from myapplication import Session
session = Session()
One (perhaps the only) advantage I can see with looking up the scoped
session as a utility is that it gives the integrator control over
whether to use one or two phase commit, as this is set in the session
configuration. Normally one would prefer one-phase commit as it is
faster, but if an integrator arranged for two applications to be
modified in a single transaction she would want to configure two-phase
commit.
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Hey Laurence,
Laurence Rowe wrote:
[snip]
We'll have to stick with scoped sesssions because of threading, but the
engine as local utility pattern should still work.
#myapplication/__init__.py
Session = scoped_session(sessionmaker(bind=LookupEngine('my-engine')...))
engine = EngineUtility(url='sqlite:///')
provideUtility(engine, IConnectable, 'my-engine') # but normally a local
utility registration
#myapplication/foo.py
from myapplication import Session
session = Session()
Here one still needs to instantiate the session each time you use it.
Couldn't you simply do:
#myapplication/__init__.py
... [what you had]
session = Session()
# myapplication/foo.py
from myapplication import session
or wouldn't that be possible?
One (perhaps the only) advantage I can see with looking up the scoped
session as a utility is that it gives the integrator control over
whether to use one or two phase commit, as this is set in the session
configuration. Normally one would prefer one-phase commit as it is
faster, but if an integrator arranged for two applications to be
modified in a single transaction she would want to configure two-phase
commit.
How common would it be that the integrator would do this without the
code itself needing to be changed for other reasons then too? A WSGI
setup, perhaps?
I imagine we could arrange something where we allow both. Provide the
engine as local utility scenario, but let people register sessions as
local utilities should they want to.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Michael Bayer wrote:
On May 7, 2008, at 7:08 AM, Martijn Faassen wrote:
Hi there (especially Christian),
I think we can work with explicits saves. In many cases the user won't
have to worry about it anyway as the container object will do it for
them (besides making the relation), or this 'query container' we spoke
of will do it for them (but just the 'save' bit).
One point is that the scoped session approach itself doesn't work very
well for using multiple databases in the same app. We could consider
passing the session along in the containers during object graph
wakling (or traversal) so an app can easily traverse into multiple
databases. I'm not sure whether we can make the ORM do this for us
though; does it initialize the mapping with a session?
SQLAlchemy's Session does support multiple engine binds itself, which
most easily can be associated with particular mapped classes (i.e.
vertical partitioning), so that a single session (or a scoped_session)
can read and write data to the appropriate tables transparently
(although things like joins across multiple databases will raise
errors). Theres a horizontally-partitioning version of Session as well
which obviously has a lot more caveats.
Using multiple sessions, one per DB is a valid approach as well.I'm
not sure if Grok has other things going on when mulitple DBs are in use
but SA's multi-bind capability is something to be aware of.
I'm thinking more about having the same classes mapped to different
databases at different points in the application. Imagine a
departmental address book app. Intstances of the departmental address
book are created for each department, each with a different databases:
http://addressbook/sales - postgres:///sales
http://addressbook/engineering - postgres:///engineering
The way I imagine this working is to have a proxy engine object that
looks up the real engine through a local utility. Each application would
be a `site` and capable of local utility registrations. /sales would
have Engine('postgres:///sales') registered and /engineering
Engine('postgres:///engineering').
Only a single ScopedSession would be required. This would be bound to
proxy that performs the utility lookup. So when in the /sales context
the proxy would point to the sales engine and when in the /engineering
context to the engineering engine.
The limitation of this approach is that it would not be possible to mix
objects from /sales and objects from /engineering into the same
transaction. So really we need a session per application instance.
Perhaps this can be achieved through a custom scoping function:
def scopefunc():
return thread.get_ident(), id(zope.component.getSiteManager())
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout Builder: Call for Ideas.
Kenneth Miller wrote: Any and all feedback is appreciated and I will carefully consider every idea. For your application: A major drawback is that the underlying architecture relies on setup file based configuration. Does it, and is it? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sqlalchemy
On May 7, 2008, at 1:29 PM, Laurence Rowe wrote:
I'm thinking more about having the same classes mapped to different
databases at different points in the application. Imagine a
departmental address book app. Intstances of the departmental
address book are created for each department, each with a different
databases:
http://addressbook/sales - postgres:///sales
http://addressbook/engineering - postgres:///engineering
The way I imagine this working is to have a proxy engine object that
looks up the real engine through a local utility. Each application
would be a `site` and capable of local utility registrations. /sales
would have Engine('postgres:///sales') registered and /engineering
Engine('postgres:///engineering').
Only a single ScopedSession would be required. This would be bound
to proxy that performs the utility lookup. So when in the /sales
context the proxy would point to the sales engine and when in the /
engineering context to the engineering engine.
The limitation of this approach is that it would not be possible to
mix objects from /sales and objects from /engineering into the same
transaction. So really we need a session per application instance.
Perhaps this can be achieved through a custom scoping function:
def scopefunc():
return thread.get_ident(), id(zope.component.getSiteManager())
If you want to mix tables (and optionally engines) for the *same*
class, we actually have a feature for that too. Its sort of a feature
I've wanted to remove but Jason keeps arguing that its worthy. It's
called entity_name and it allows multiple primary mappers to be
created for a single class. The entity_name has to be specified when
you add the element to the session (yet another reason explicit add()
is a good thing). This feature is taken directly from the Hibernate
feature of the same name.
The limitation with entity_name which needs some more fixing in 0.5 is
that only one mapper gets to define the attribute instrumentation for
the entity. If you are storing the same class in three different
tables (across three different databases or just one), the attributes
defined on the class need to be compatible with all three. This is
reasonable since a class can only have one descriptor per attribute
name. Querying is also slightly challenging since the descriptors
need to be qualified for a particular mapper (i.e. you cant just say
query.filter(Address.id==5)...which id are we talking about ?)
The reason I'm not totally keen on this feature is that it seems to be
a very exotic way of getting around making simple subclasses, and I've
yet to see the use case for it where simple subclasses don't work,
except for cosmetic reasons which I have a hard time swallowing
(even if the reasons are cosmetic, you can still create subclasses
that are all named the same).
So I will ask you, why can't your application simply have a
SalesAddress and an EngineeringAddress class ? You could even
produce them transparently using a custom __new__() method, i.e.
class Address(object):
def __new__(cls, *args, **kwargs):
if my_scoped_thing.context == 'sales':
return object.__new__(SalesAddress)
elif my_scoped_thing.context == 'engineering':
return object.__new__(EngineeringAddress)
this seems extremely straightforward to me as each object, once
instantiated is now bound for a specific destination. It doesnt seem
like youd want the *same* Address to be stored in one and then the
other in a different instance (that seems *extremely* complex for no
good reason). Isnt explicit better than implicit ?
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout Builder: Call for Ideas.
Malthe Borch wrote: For^D^D^DFrom your application... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Michael Bayer wrote: So I will ask you, why can't your application simply have a SalesAddress and an EngineeringAddress class ? You could even produce them transparently using a custom __new__() method, i.e. class Address(object): def __new__(cls, *args, **kwargs): if my_scoped_thing.context == 'sales': return object.__new__(SalesAddress) elif my_scoped_thing.context == 'engineering': return object.__new__(EngineeringAddress) this seems extremely straightforward to me as each object, once instantiated is now bound for a specific destination. It doesnt seem like youd want the *same* Address to be stored in one and then the other in a different instance (that seems *extremely* complex for no good reason). Isnt explicit better than implicit ? When the generic address book application is built you don't know what the departments will be called or indeed how many departments there are. An address book is not be a great example, but I know of intranet portal sites where this is a requirement. You want to delegate control to each department so you give each department their own instance of the portal. You only want to maintain one code base though, and you don't want to change it every time someone adds another departmental portal. I'd like to be able to create an add form that has fields for application name and database url. This probably seems like an odd requirement -- why not just run multiple processes with different configurations -- but it's the way zope has traditionally worked. A single process can serve multiple instances of the same application (or `site`). When you get up to running tens of sites, the memory footprint of Zope2 and Plone (before the object cache) becomes significant. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sqlalchemy
On May 7, 2008, at 2:29 PM, Laurence Rowe wrote: When the generic address book application is built you don't know what the departments will be called or indeed how many departments there are. An address book is not be a great example, but I know of intranet portal sites where this is a requirement. You want to delegate control to each department so you give each department their own instance of the portal. You only want to maintain one code base though, and you don't want to change it every time someone adds another departmental portal. I'd like to be able to create an add form that has fields for application name and database url. This probably seems like an odd requirement -- why not just run multiple processes with different configurations -- but it's the way zope has traditionally worked. A single process can serve multiple instances of the same application (or `site`). When you get up to running tens of sites, the memory footprint of Zope2 and Plone (before the object cache) becomes significant. If you are running different instances each connected to a different engine within one process you wouldn't need any awareness of engines at the object level (therefore no entity_name) and also no engine proxying - you should have separate Session instances for each process managed by scoped_session(), which was designed to handle this.Multiple apps on one codebase within one process was an original requirement of Pylons as well, though nobody has ever used it. The easiest way to do it is to set up the engine at the request level: Session = scoped_session() # start of request engine = get_appropriate_engine() Session(bind=engine) try: # do request finally: Session.remove() If that isnt granular enough, then you use a custom scope func which maintains Session per-process-per-thread. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Laurence Rowe wrote:
Martijn Faassen wrote:
Hey Laurence,
Laurence Rowe wrote:
[snip]
We'll have to stick with scoped sesssions because of threading, but
the engine as local utility pattern should still work.
#myapplication/__init__.py
Session =
scoped_session(sessionmaker(bind=LookupEngine('my-engine')...))
engine = EngineUtility(url='sqlite:///')
provideUtility(engine, IConnectable, 'my-engine') # but normally a
local utility registration
#myapplication/foo.py
from myapplication import Session
session = Session()
Would session = ISession(context) be a reasonable way for grok to handle
this?
Making transactions span multiple instances of a single app seems
impossible otherwise, though maybe that is an edge case that need not be
supported.
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AW: Re: New i18n locale extraction concept
Hi Roger,
Roger Ineichen, on 2008-05-01:
I agree, a tool whould be great. But the first we need to
offer i18n extract script which can handle our new egg
based buildout process. z3c.recipe.i18n is the only one
which could handle this right now.
Ideally, the recipe i18n tool should be able to extract,
merge, and give stats, just like in the monolithic zope release.
Yes, z3c.recipe.i18n does this right now. The -d option uses
one or more egg or develop externals as argument instead of
one single path.
Some comments on that z3c.recipe.i18n
In README.txt you first mention z3c.recipe.start, then the i18n recipe
and then the app recipe. Is the same meant in all three cases?
I like that it can extract locales from eggs. I don't like that it
uses zcml for this. Is the zcml really necessary?
Why specify both eggs and packages? And why specify those packages in
the setup.py too? At least that is what I see in zam.locales.
The tests don't run on Linux as there are Windows specific checks in
them, for example:
File .../z3c.recipe.i18n/src/z3c/recipe/i18n/README.txt, line 121,
in README.txt
Failed example:
ls('bin')
Expected:
- buildout-script.py
- buildout.exe
- i18nextract-script.py
- i18nextract.exe
- i18nmergeall-script.py
- i18nmergeall.exe
- i18nstats-script.py
- i18nstats.exe
Got:
- buildout
- i18nextract
- i18nmergeall
- i18nstats
Of course quite likely there are also a lot of Linux/Mac packages that
fail on Windows because of similar reasons. :-/
--
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
This is your day, don't let them take it away. [Barlow Girl]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] Re: AW: Re: New i18n locale extraction concept
Hi Maurits
Thanks for your feedback,
Betreff: [Zope-dev] Re: AW: Re: New i18n locale extraction concept
Hi Roger,
Roger Ineichen, on 2008-05-01:
I agree, a tool whould be great. But the first we need to
offer i18n
extract script which can handle our new egg based buildout process.
z3c.recipe.i18n is the only one which could handle this right now.
Ideally, the recipe i18n tool should be able to extract,
merge, and
give stats, just like in the monolithic zope release.
Yes, z3c.recipe.i18n does this right now. The -d option uses one or
more egg or develop externals as argument instead of one
single path.
Some comments on that z3c.recipe.i18n
In README.txt you first mention z3c.recipe.start, then the
i18n recipe and then the app recipe. Is the same meant in
all three cases?
Uhaaa, that's a left over from a copied README.txt file.
I need to review that part again.
I like that it can extract locales from eggs. I don't like
that it uses zcml for this. Is the zcml really necessary?
zcml is needed for exctract locales from page templates.
Why specify both eggs and packages? And why specify those
packages in the setup.py too? At least that is what I see in
zam.locales.
Eggs are needed for setup your project, or probably a working
setup like in any other package.
Packages are used for extract locales from. That could be very
different then the egg setup. The i18nextrac.py will only deep
into this packages, but probably this packages will need different
eggs which they import from.
Note, if you run the i18nextract script, all module must be
there like in a running application. You can't only use
the files which will contain locales. Also modules which
this packages import from must be there.
This isn't aproblem since the zope.app.locales dependes on
everyting which we developed the last years. Because
zope.app.locales depends on almost everything.
The tests don't run on Linux as there are Windows specific
checks in them, for example:
File .../z3c.recipe.i18n/src/z3c/recipe/i18n/README.txt, line 121,
in README.txt
Failed example:
ls('bin')
Expected:
- buildout-script.py
- buildout.exe
- i18nextract-script.py
- i18nextract.exe
- i18nmergeall-script.py
- i18nmergeall.exe
- i18nstats-script.py
- i18nstats.exe
Got:
- buildout
- i18nextract
- i18nmergeall
- i18nstats
Of course quite likely there are also a lot of Linux/Mac
packages that fail on Windows because of similar reasons. :-/
I see, I 'll add a normalizer for that. I thought it was already
there, but could be not correct implemented.
Regards
Roger Ineichen
--
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/ This is your day,
don't let them take it away. [Barlow Girl]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! ** (Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
