Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
whit wrote:
I'm not clear on what the advantage would be. I'm probably missing some use cases. I think they are both valid approaches to the problem.
my main usecase is to be able to use buildouts in a workingenv without having to rewrite the recipes... right now, I have to do one or the other.
Sure. I still don't know what that means. :) *Maybe* you'd like to use workingenv to install eggs and use buildout to do other things like set up zope instances. If that's the case, then it's just a matter of writing recipes that take into account how you install eggs and scripts. But maybe that's not what you mean. ...
If people really see value in having buildout and workingenv work together, perhaps Ian and I could explore this a bit at PyCon next month.
+1. my general feeling is that there is a enough overlap that this would be beneficial.
Specific use cases would help to guide this.
try to justify why a zope hammer is better and why zope folk keep building new hammers that don't play nice with everyone else's hammer loses us cred.
You seem to be implying that workingenv is somehow a standard tool and that buildout is a zope-specific tool that needlessly duplicates a standard tool. I was perhaps offbase in my comment about egg handling. workingenv of course is not a standard tool. what I'm presenting here is a perspective I face on a regular basis; for a developer using workingenv already, it's far more standard than something else he is not using...and vice versa.
No, it's more familiar -- to these people.
in the case of tools that enable a developer to start quickly, developers are very difficult to ween from habits that are currently working. when a large and complex task such as building plone becomes codified in a technology that is not familar or easily compatible with the the developers current environment, it's an issue.
The alternative seems to be a custom shell script. I can see how this would be familiar to the people who wrote it. When there are well established and documented buildout recipes for doing common tasks, then there will be familiar tools, for some definition of familiar.
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 one depends on the other or not. That's true for languages, companies, frameworks and everything else.
I think it really depends whether something transcends it's immediate community(and maybe here whether a z floats in front of it's name somewhere).
So lets see. To contribute to the wider Python community, I should change the name of my Company or change jobs. Hm.
for packages from zope or plone people, if they rides roughly with existing python techs
In what way does buildout "ride roughly with existing python techs". It builds on setuptools. Do you mean that if there is another community package that does something somewhat similar, we aren't allow to create a similar package just because we are associated with the Zope project.
and come from a zopeish repository,
Oh, I have to use a different repository.
sadly they are liable to get branded w/ a legacy reputation that haunts the name.
Has it occurred to you that the problem here doesn't lie with the Zope project or Zope developers?
inversely, those of us zope and plonistas may be a bit uncritical of projects coming from close to home
Oh, as someone who gets lots of criticism, I really don't think that is much of a problem.
and allow such technologies to stay inaccessible to wider audiences.
How are we doing this? The primary forum for discussing buildout is the distutils sig. It is released through PyPI. It doesn't depend on any other technology that we use -- other than Python. What should I do to make it more accessible? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
whit wrote:
I'm not clear on what the advantage would be. I'm probably missing some use cases. I think they are both valid approaches to the problem.
my main usecase is to be able to use buildouts in a workingenv without having to rewrite the recipes... right now, I have to do one or the other.
Sure. I still don't know what that means. :)
*Maybe* you'd like to use workingenv to install eggs and use buildout to do other things like set up zope instances. If that's the case, then it's just a matter of writing recipes that take into account how you install eggs and scripts. But maybe that's not what you mean.
...
If people really see value in having buildout and workingenv work together, perhaps Ian and I could explore this a bit at PyCon next month.
+1. my general feeling is that there is a enough overlap that this would be beneficial.
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 plone). I'd like with minimal effort to have build in my setup without having to dig too deep into the existing buildout or the framework driving it. This might be as simple as having buildout(at my own risk), do less with creating special pythonpaths in scripts(or perhaps just appending the existing one as the zope2 zopectl script does now). I'd also like to have the development eggs and normal eggs go where I currently have my eggs(lib/python, /src). as I believe you've pointed out that can be done by simple modification of the cfg file and that'd be fine.
try to justify why a zope hammer is better and why zope folk keep building new hammers that don't play nice with everyone else's hammer loses us cred.
You seem to be implying that workingenv is somehow a standard tool and that buildout is a zope-specific tool that needlessly duplicates a standard tool. I was perhaps offbase in my comment about egg handling. workingenv of course is not a standard tool. what I'm presenting here is a perspective I face on a regular basis; for a developer using workingenv already, it's far more standard than something else he is not using...and vice versa.
No, it's more familiar -- to these people.
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.
in the case of tools that enable a developer to start quickly, developers are very difficult to ween from habits that are currently working. when a large and complex task such as building plone becomes codified in a technology that is not familar or easily compatible with the the developers current environment, it's an issue.
The alternative seems to be a custom shell script. I can see how this would be familiar to the people who wrote it. When there are well established and documented buildout recipes for doing common tasks, then there will be familiar tools, for some definition of familiar.
this is where rob started with our deployment strategy. I like buildit and buildout's codification of what happens in a build in cfg file since it creates a fairly auditable place to see what is happening(as well as extend it). we are going to re-write the shell scripts using buildit and if plone uses zc.buildout, would like not to have to replicate that part in our own system.
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 one depends on the other or not. That's true for languages, companies, frameworks and everything else.
I think it really depends whether something transcends it's immediate community(and maybe here whether a z floats in front of it's name somewhere).
So lets see. To contribute to the wider Python community, I should change the name of my Company or change jobs. Hm.
for packages from zope or plone people, if they rides roughly with existing python techs
In what way does buildout "ride roughly with existing python techs". It builds on setuptools. Do you mean that if there is another community package that does something somewhat similar, we aren't allow to create a similar package just because we are associated with the Zope project.
and come from a zopeish repository,
Oh, I have to use a different repository.
sadly they are liable to get branded w/ a legacy reputation that haunts the name.
Has it occurred to you that the problem here doesn't lie with the Zope project or Zope developers?
inversely, those of us zope and plonistas may be a bit uncritical of projects coming from close to home
Oh, as someone who gets lots of criticism, I really don't think that is much of a problem.
and allow such technologies to stay inaccessible to wider audiences.
How are we doing this? The primary forum for discussing buildout is the distutils sig. It is released through PyPI. It doesn't depend on any other technology that we use -- other than Python.
What should I do to make it more accessible?
jim, this is not a personal attack on zope corp or the good work you guys have done. It is merely an observation about our entire community concerning some of social factors pertinent to this end of the python pond stated as an answer to what was obviously a rhetorical question by you. I apologize if it seemed otherwise. I won't address your new set rhetorical questions/statements, except to say that we, zope community in toto, are the only people who can take action on our side of our relationship with the rest the world. in making zc.buildout a widely useful minimal dependency technology and by taking part in this conversation(as acrimonious as it may seem at this point), I think you are positively effecting this relationship. Hopefully the outcome of this conversation will mean that plone using zc.buildout won't in any way be divisive for people who choose different ways of setting up their development environments and have one less reason to bounce off of plone and therefore zope. -w -- ------ d. whit morriss ------ - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995
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 plone).
Does this recipe create something in particular? A Plone instance? A Plone software install?
I'd like with minimal effort to have build in my setup without having to dig too deep into the existing buildout or the framework driving it.
By "have build in my setup", you mean, use buildout in your setup to leverage Hanno's recipe?
This might be as simple as having buildout(at my own risk), do less with creating special pythonpaths in scripts(or perhaps just appending the existing one as the zope2 zopectl script does now).
The eggs recipe let's you add paths not provided by scripts. Other recipes that extend the eggs recipe typically let you do this too. I'm not sure if this is what you are getting at.. If you could get a bit more specific, then so could I. :)
I'd also like to have the development eggs and normal eggs go where I currently have my eggs(lib/python, /src). as I believe you've pointed out that can be done by simple modification of the cfg file and that'd be fine.
Yup. I'll repeat that allowing for shared eggs across buildouts can be a major win. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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 one depends on the other or not. That's true for languages, companies, frameworks and everything else.
I think it really depends whether something transcends it's immediate community(and maybe here whether a z floats in front of it's name somewhere).
So lets see. To contribute to the wider Python community, I should change the name of my Company or change jobs. Hm.
for packages from zope or plone people, if they rides roughly with existing python techs
In what way does buildout "ride roughly with existing python techs". It builds on setuptools. Do you mean that if there is another community package that does something somewhat similar, we aren't allow to create a similar package just because we are associated with the Zope project.
and come from a zopeish repository,
Oh, I have to use a different repository.
sadly they are liable to get branded w/ a legacy reputation that haunts the name.
Has it occurred to you that the problem here doesn't lie with the Zope project or Zope developers?
inversely, those of us zope and plonistas may be a bit uncritical of projects coming from close to home
Oh, as someone who gets lots of criticism, I really don't think that is much of a problem.
and allow such technologies to stay inaccessible to wider audiences.
How are we doing this? The primary forum for discussing buildout is the distutils sig. It is released through PyPI. It doesn't depend on any other technology that we use -- other than Python.
What should I do to make it more accessible?
jim, this is not a personal attack on zope corp or the good work you guys have done.
It is merely an observation about our entire community concerning some of social factors pertinent to this end of the python pond stated as an answer to what was obviously a rhetorical question by you. I apologize if it seemed otherwise.
You should read what you said above carefully, if you haven't already.
I won't address your new set rhetorical questions/statements, except to say that we, zope community in toto, are the only people who can take action on our side of our relationship with the rest the world.
That's right, we are the only ones who can take action on our side. So, what have we done: - We've adopted standard technologies that let us work with others, like setuptools and wsgi. - We are actively looking at ways to leverage other technologies, (e.g. templating technologies and paste deploy). - We designed Zope 3 specifically to more easily leverage and be leveraged by other systems, - We are splitting up our software and distributing it as eggs to the wider Python community. - We actively participate in the Python community, through conferences and sigs.
in making zc.buildout a widely useful minimal dependency technology and by taking part in this conversation(as acrimonious as it may seem at this point), I think you are positively effecting this relationship.
I hope so, That's why I'm participating. But, is there any reason why discussions like this have to be acrimonious? Here are some suggestions (these are for all of the participants here): - Stick to technical content. Try to resist attacking people's attitudes and motivations, which you might not really know. - On technology, please try to stick to specifics that people can actually respond to, rather than generalities. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (2)
-
Jim Fulton -
whit