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

[Jim Fulton]

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 at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org