[Zope-dev] Re: [ZPT] RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-19 Thread Ian Bicking
either, as it feels like boilerplate. I suppose path('formatters:nl2br')(path('options/message')) is maybe a little better, but only a very little. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Zope-Dev maillist - [EMAIL

[Zope-dev] Re: [ZPT] Re: RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-21 Thread Ian Bicking
. Or maybe if I got used to it the grouping would seem more natural. I guess my intuition is that / binds more closely than : (even if there isn't any real precedence at all in TAL expressions). -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org

[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-25 Thread Ian Bicking
whit wrote: Not everybody likes the activate dance. With buildout, you don't need it. The recipes make sure that the scripts that get installed into the buildout's 'bin' directory have the right PYTHONPATH set and have access to the eggs you requested for the buildout. is there really a

Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-25 Thread Ian Bicking
standard site.py), and doesn't describe intent, it's just an enumeration of what is available and activated (i.e., available without specifically requiring something). Besides all that, it's still a workable foundation IMHO. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org

Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-25 Thread Ian Bicking
be to have a tool that allows you to easily include something from the system Python (probably just a tool to manage a custom .pth file, which works even when setuptools' fairly heroic attempts to fix broken setup.py's doesn't work). -- Ian Bicking | [EMAIL PROTECTED] | http

[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-27 Thread Ian Bicking
Martin Aspeli wrote: I don't have a usecase for executing the scripts with any python interpeter other than the one which ran setuptools to generate them, and therefore don't care for the hard-wired path manipulation I would agree that having to mangle multiple scripts is annoying. On the

[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-27 Thread Ian Bicking
Martin Aspeli wrote: I don't have a usecase for executing the scripts with any python interpeter other than the one which ran setuptools to generate them, and therefore don't care for the hard-wired path manipulation I would agree that having to mangle multiple scripts is annoying. On the

[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-28 Thread Ian Bicking
Martin Aspeli wrote: Eggs exist to pkg_resources (the runtime portion of setuptools) simply by being available on a path. E.g., if you have lib/python/ on the path, and lib/python/Foo-1.0.egg/ exists, then if you do pkg_resources.require('Foo') that will add lib/python/Foo-1.0.egg/ to the

[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-28 Thread Ian Bicking
Martin Aspeli wrote: whit wrote: actually, in my current workplace, workingenv is the standard way to set up one's dev environment. but in the context of the previous statement, familar is perhaps a better word. I'm still not clear how widely used workingenv is? Is it officially endorsed

[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-29 Thread Ian Bicking
Jim Fulton wrote: Ian Bicking wrote: What I would *like* the distinction between workingenv and buildout to be is that workingenv is interactive (i.e., install with easy_install) and buildout is declarative (i.e., specify your environment with buildout.cfg). Well said. I was looking

[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-29 Thread Ian Bicking
scripts. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ 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

Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

2007-01-29 Thread Ian Bicking
Jim Fulton wrote: Ian Bicking wrote: Martin Aspeli wrote: whit wrote: actually, in my current workplace, workingenv is the standard way to set up one's dev environment. but in the context of the previous statement, familar is perhaps a better word. I'm still not clear how widely used

[Zope-dev] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-03 Thread Ian Bicking
as an argument for ploneout, just because ploneenv hasn't seen a Windows developer yet. :-) Workingenv does, as far as I know, work with Windows. At least I've received several patches (I've never used it myself). -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org

[Zope-dev] Re: [Repoze-dev] repoze.bfg

2008-07-17 Thread Ian Bicking
kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org

[Zope-dev] Re: [Repoze-dev] repoze.bfg

2008-07-17 Thread Ian Bicking
endpoints, but those can grow over time. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http