Summary of messages to the zope-tests list.
Period Sat Jan 27 12:00:00 2007 UTC to Sun Jan 28 12:00:00 2007 UTC.
There were 7 messages: 7 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2.6 Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Sat Jan 27 21:04:47 EST 2007
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
Martin Aspeli wrote:
This thread is getting rather long... :)
But except for the interaction of workingenv and buildout, which I'm not
smart enough to say anything useful about, we are almost finished ;)
- There is a 2.5 branch of ploneout
(http://svn.plone.org/svn/ploneout/branches/2.5)
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
Ian Bicking wrote:
...
I would assume that buildout is specifically disabling easy_install's
updating of easy-install.pth
WRT egg installation, buildout follows easy_install's multi-version model.
It installs eggs in such a way that multiple versions can be installed
at the same time. As
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together. I have some guesses,
but I'd rather hear people say what they
whit wrote:
...
Specific use cases would help to guide this.
the main usecase for me is the following... hanno writes a recipe for
plone, and I want to use that recipe as part of setting up a openplans
development environment (for example inside my workingenv that I've been
developing w/out
whit wrote:
Jim Fulton wrote:
...
zc.buildout is in no way zope specific. Can a Zope developer not
develop a tool without it being stamped as zope specific?
maybe... maybe not. When a developer struggles with more than one
tool from the same general source, it matters little to them whether
Ian Bicking wrote:
Martin Aspeli wrote:
...
If lib/python/Foo-1.0.egg/ is on the path to start with you can
import from it directly.
This is what zc.reipe.egg does I believe.
It activates (i.e., adds eggs to the path) in the scripts. I think
setuptools' egg activation will be
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 workingenv is? Is it
Martin Aspeli wrote:
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together. I have some guesses,
but I'd rather hear
Jim Fulton wrote:
Martin Aspeli wrote:
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together. I have some guesses,
- ploneout (http://svn.plone.org/svn/plone/ploneout/trunk) is really
an environment that Plone 3 core developers could (should?) use as a
consistent way of setting up a Zope 2.10 instance with Plone 3 and all
dependencies. It uses svn:externals quite extensively to pull in Plone's
source
Martin Aspeli wrote:
Jim Fulton wrote:
Martin Aspeli wrote:
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together.
Jim Fulton wrote:
[foo]
recipe=zc.recipe.egg
eggs = egg1 egg2 ...
interpreter = mypy
extra-paths = path-to-your-instance/lib/python
scripts = mypy
This is great :) I used eggs = ${instance:eggs} to make sure it has the
same eggs as our Zope instance, seems to
Hi,
I had a few minutes to spare and took a quick look at the implementation.
Philipp von Weitershausen wrote:
As for the implementation, I gave it my best shot in the
philikon-aq-and-__parent__ branch. My experience with C is limited,
especially when it comes to debugging. Help is therefore
16 matches
Mail list logo
