Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 02:44, Chris McDonough chr...@plope.com wrote: But I couldn't really figure out a way to do the moral equivalent of this: .. code-block:: python a == 1 .. manuel-expect: True Maybe I missed it. I couldn't either. So I added a sphinx module for Manuel, supporting Sphinx testsetup/testcode/testoutput statements. Missing so far is: - support for groups, - in particular the * group for testsetup, - support for having doctest statements mixed with the above, so you can have statements but put output in a testoutput statement, If the code is acceptable to Manuel people, I'll might work on it some more until my usecases work. :) On the other hand I might abandon this path completely, and make all my testing *not* be doctests, but use Sphinx literal-include instead, and run the tests some other way, because as usual doctests are turning out the be a shitload of work for very little benefit. Also if the above code is deemed as being a Good Idea, I will remove all the usage of zope.testing.doctest from Manuel. This is necessary, as one of the things I need from Manuel is a Python 3 port, and I'm not porting zope.testing.doctest to Python 3. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
Lennart Regebro wrote: [snip] Also if the above code is deemed as being a Good Idea, I will remove all the usage of zope.testing.doctest from Manuel. This is necessary, as one of the things I need from Manuel is a Python 3 port, and I'm not porting zope.testing.doctest to Python 3. I think this is quite independently from the above the consensus anyway, right? Switching over from zope.testing.doctest to plain doctest anywhere seems like a good idea. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [Announce] BlueBream: Script to setup a Zope project directory
Hi All, I started a project named BlueBream to create a script to setup a Zope project directory. BlueBream use ZTK with some additional packages. BlueBream is based on PasteScript's template plugin. The package is available from PyPI: http://pypi.python.org/pypi/bluebream Source code is available from my Sandbox: svn://svn.zope.org/repos/main/Sandbox/baijum/bluebream/trunk Looking for your feedback. Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Announce] BlueBream: Script to setup a Zope project directory
On Sun, Jan 3, 2010 at 9:20 PM, Andreas Jung li...@zopyx.com wrote: How is this different from ZopeSkel? Well, it's just yet another PasteScript project template. BlueBream provides a slightly different layout compared to basic_zope . Here are few features: 1. BlueBream project package includes ZTK + few additional packages which was part of Zope 3. 2. Runnable Buildout 3. Functional testing enabled by default using z3c.testsetup 4. Use PasteDeploy 5. Create a namespace package by default. To use: $ easy_install bluebream $ paster create -t bluebream testproject $ cd testproject $ python bootstrap.py $ ./bin/buidout $ ./bin/test $ ./bin/paster serve debug.ini Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Announce] BlueBream: Script to setup a Zope project directory
On 2010-01-03, Baiju M mba...@zeomega.com wrote: On Sun, Jan 3, 2010 at 9:20 PM, Andreas Jung li...@zopyx.com wrote: How is this different from ZopeSkel? Well, it's just yet another PasteScript project template. BlueBream provides a slightly different layout compared to basic_zope . Another obvious question (sorry ;-), why not just contribute to ZopeSkel (which is currently in need of some active contributors, IIRC)? Here are few features: 1. BlueBream project package includes ZTK + few additional packages which was part of Zope 3. 2. Runnable Buildout 3. Functional testing enabled by default using z3c.testsetup 4. Use PasteDeploy 5. Create a namespace package by default. To use: $ easy_install bluebream $ paster create -t bluebream testproject $ cd testproject $ python bootstrap.py $ ./bin/buidout $ ./bin/test $ ./bin/paster serve debug.ini Nice! Can I suggest adding that last bit to the PyPI page? E.g. $ cd testproject $ python bootstrap.py $ ./bin/buidout $ ./bin/test $ ./bin/paster serve debug.ini Also, there are a few installation issues (fixed by running `mkdir -p` by hand): http://pastie.org/765137 http://pastie.org/765140 And runtime issues (I think?): http://pastie.org/765143 Otherwise, it works as expected :-) Alex Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) --- Alex Clark · http://aclark.net Practical Plone 3 · http://tinyurl.com/practical-plone ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] broken zope.publisher because of new content types in zope.contenttype
Hey,
Roger wrote:
Since aaron added new mimetypes e.g. application/javascript,
the _implicitResult method in zope.publisher.http.py (line 794)
is broken because the method checks for text/* content types
if unicode is given:
def _implicitResult(self, body):
encoding = getCharsetUsingRequest(self._request) or 'utf-8'
content_type = self.getHeader('content-type')
if isinstance(body, unicode):
try:
if not content_type.startswith('text/'):
raise ValueError(
'Unicode results must have a text content type.')
except AttributeError:
raise ValueError(
'Unicode results must have a text content type.')
Sould we remove this basic content type check above?
Or enhance the check with the new added unicode valid
content types like application/javascript.
btw, the RFC is just Informational which defines
this changes. See: http://www.rfc-editor.org/rfc/rfc4329.txt
We don't seem to be getting test failures anywhere in the ZTK. Could you
propose a test that identifies this issue?
Aaron, can you give feedback about this issue?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] how to help Martijn (how can we have better discussions?)
Hi there, A meta-discussion, how dangerous! Let's see whether it can help us improve the way we work together, though. I'll talk about how I think, from my perspective, we can improve the quality of discourse on this mailing list and be more constructive. What lowered the quality of this discussion? I think it is because various people became quite upset and annoyed. That's because I reverted Hanno's changes to the ZTK trunk. I shouldn't have done that just like that, but I needed the subsequent discussion to come up with a better solution. In the turmoil, my attempts to formulate a solution that would satisfy everybody's concerns fairly well seemed to have been overlooked a little bit. Instead we focused a lot of time on discussing bits we ironically enough actually more or less agreed about, such as the role of the ZTK. Nobody seemed to quite notice that I'm in fact in favor of a smaller ZTK, even though I said so repeatedly. That's because I'm *also* in favor of maintaining the zopeapp bits a while longer and not just throwing those away. I want an exit strategy for those bits. A transition strategy. That is a legitimate topic for this mailing list at the very least. Instead, we had endless debates about whether it was a legitimate concern for the ZTK maintainers. I'm of course still right that it is. I have wonderful and coherent reasons to support my position just like everybody else does who disagrees with me. It's not really very important anyway. We're here together on this list to work together beyond the ZTK itself. So how can we have better discussions? We can have better discussions by helping me. How can you help me? Of course it helps if you agree with me. I realize that's frequently infeasible, but I certainly wouldn't mind. :) If you disagree with me, I'd like you to try to understand my concerns as much as you possibly can. In addition, try acknowledge my concerns as much as you possibly can without feeling you're lying. This works beter than just rejecting them. How else can you help me? You can propose realistic solutions for how we as a community can take care of these concerns that I have. And still fulfill your concerns at the same time. Such solutions were entirely possible in this discussion. Constructive debating is an art I'm still learning, but I had the feeling people enjoyed the rest of the debate too much to be very constructive this time... Of course the way you'd help me is the way anybody would be helped in a discussion, as the discussion becomes more constructive. Again, I know as much to blame as anyone else. I helped spark it due to my revert and my continued insistence that I am right. The revert shouldn't have happened. But I didn't know that at the time as I hadn't had time to think yet either. So how else can you help me? Give me some space to think. I believe my concerns could have been easily taken care of if we'd stopped and talked for a little bit *before* drastic changes were checked in. So, you can help me by discussing things that you know are drastic changes before you do them. I know we have had a lot of problems reaching conclusions in such discussions in the past, but we can't learn how to do better at that if we don't. And we are going to do better if I can help it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] shrinking the ZTK: a proposed solution
Hi there, So here's my proposed solution for the ZTK shrinking issue: The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since Zope 2 forked the ZTK in response and continued to make changes to their fork, I've tried to keep it in sync with the Zope 2 fork. I've created a new 'zopeapp' package that expands the ZTK with zope.app. packages in my sandbox. This extracts that information from the ZTK. Hopefully after we get some feedback from other steering group members (very silent indeed in the holiday period when all this happened) we can make these two projects the official one: a ZTK project and a zopeapp project. A few things I ask the ZTK maintainers: I ask the ZTK maintainers to have the same concern for the zope.app packages as for any other user of the ZTK: work to support zopeapp's compatibility with the ZTK. If the zopeapp maintainers have issues, listen to them seriously. I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people) I also strongly encourage the ZTK maintainers to consider the situation of backwards compatibility seriously. Help people transition from their code now to the ZTK. Helping everybody migrate to the ZTK smoothly increases the value of the ZTK itself. Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers. I also think we as ZTK maintainers should better consider the concerns of other users of the ZTK. In this case, Zope 2 had less of a concern for zope.app than Grok or Zope 3. I didn't even understand this until the debate was further along. The concerns of others should be considered as well instead of simply rejected. We usually can find ways to balance the concerns of everybody. To that end concerns (or lack thereof) should be clearly communicated and be listened to. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
On Sat, Jan 2, 2010 at 8:44 PM, Chris McDonough chr...@plope.com wrote: Python samples in Sphinx docs are generated like so: .. code-block:: python a == 1 I did a bit of fooling around with Manuel, because I wanted to make sure that the code blocks in my documentation actually worked, but I wound up in a place where I use Manuel to check only the *syntax* of a subets of the Sphinx code blocks I use. It will do this right out of the box if you read the Manuel docs But I couldn't really figure out a way to do the moral equivalent of this: .. code-block:: python a == 1 .. manuel-expect: True Sphinx and Manuel both support interpreter blocks, so the normal approach will work: a == 1 True Occasionally you want to show some code but hide the assertions about the effects of the code. You can do that by putting the tests in a reST comment after the code. .. code-block:: python a = Foo() b = a.bar() .. make sure the above worked correctly b.baz 42 -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
Martin Aspeli wrote: [snip] We've had good success with http://pypi.python.org/pypi/collective.recipe.sphinxbuilder I'm having trouble with this. I'm trying to set up a narrative_docs directory in a package but: * the documentation on collective.recipe.sphinxbuilder pypi talks about a bin/sphinxbuilder script. That simply isn't there (the sphinx-build and sphinx-quickstart commands are). Ah, I see it is named after my section. The documentation didn't say that. * I'm supposed to run sphinx-quickstart by hand and answer a few questions and choose docs-source as your source folder. I'd like to tell about my source folder, but instead it asks me for a root path for the documentation. I cannot directly control the source path at all, only whether it is the root path or whether it's in root_path/source. * I'd prefer it if I ended up with a sphinx quickstart script that got preconfigured with the choices I made in buildout anyway, or perhaps even run quickstart itself when necessary (but a manual step here is okay and perhaps the sanest) There's also a z3c.recipe.sphinxdoc recipe. This seems to be geared towards producing sphinx documentation from doctests within a Python package. I think to encourage narrative documentation I'd like to separate this documentation from the source tree (though I *would* like to have the *option* to use doc tests). * Do I need to answer 'y' or 'no' to the 'Create Makefile' question and a windows command file? This is definitely frustrating. :) I want to document something about this so that people have more guidance and that our ZTK packages have a similar documentation structure,... Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
On Wed, Dec 30, 2009 at 7:45 AM, Marius Gedminas mar...@gedmin.as wrote: On Wed, Dec 30, 2009 at 08:58:52AM +0100, Lennart Regebro wrote: On Tue, Dec 29, 2009 at 23:47, Marius Gedminas mar...@gedmin.as wrote: * support for the INTERPRET_FOOTNOTES feature Then they should use Manuel. Good, so we have a migration path for this bit! How mechanical can such a transformation be? The transformation should be reasonably mechanical. Something like this (untested): m = manuel.footnote.Manuel() m += manuel.doctest.Manuel(**kw) return manuel.testing.TestSuite(m, 'foo.txt') -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 4:48 PM, Lennart Regebro rege...@gmail.com wrote:
On Sun, Jan 3, 2010 at 22:08, Benji York be...@zope.com wrote:
Occasionally you want to show some code but hide the assertions about
the effects of the code. You can do that by putting the tests in a reST
comment after the code.
.. code-block:: python
a = Foo()
b = a.bar()
.. make sure the above worked correctly
b.baz
42
That doesn't work for code that will raise an exception.
Also, if you want to both run a command and make sure it's output is
correct, then you need to do that twice.
In both of those cases normal doctest blocks seem appropriate.
Calling foo with the wrong parameters raises an exception:
foo('wrong')
Traceback (most recent call last):
...
ValueError: bad parameters
Calling the hello function prints a greeting.
hello()
Hello world!
--
Benji York
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 6:53 AM, Martijn Faassen faas...@startifact.com wrote: Lennart Regebro wrote: [snip] Also if the above code is deemed as being a Good Idea, I will remove all the usage of zope.testing.doctest from Manuel. This is necessary, as one of the things I need from Manuel is a Python 3 port, and I'm not porting zope.testing.doctest to Python 3. I think this is quite independently from the above the consensus anyway, right? Switching over from zope.testing.doctest to plain doctest anywhere seems like a good idea. Manuel uses the standard library's doctest almost exclusively. The only place zope.testing.doctest is used is to be compatible with zope.testing's expectations. I just took a stab at removing all references to zope.testing.doctest from Manuel and got it to work using the zope.testing trunk (Manuel needs DocTestFailureException). -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 23:14, Benji York be...@zope.com wrote: In both of those cases normal doctest blocks seem appropriate. Not if you don't want the output in the formatting, or if you don't want the brackets. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 23:38, Benji York be...@zope.com wrote: I just took a stab at removing all references to zope.testing.doctest from Manuel and got it to work using the zope.testing trunk (Manuel needs DocTestFailureException). Awesome! That would make it easy to port to Python 3, which I need. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
Lennart Regebro wrote:
On Sun, Jan 3, 2010 at 23:14, Benji York be...@zope.com wrote:
In both of those cases normal doctest blocks seem appropriate.
Not if you don't want the output in the formatting, or if you don't
want the brackets.
Yeah. I haven't thought about this much, so it might be bollocks, but I think
something like this is what I'm after:
.. code-block-setup::
import sys
from somepackage.testing import DummyModule
sys.modules['models'] = DummyModule()
.. code-block:: python
:linenos:
from models import MyModel
from repoze.bfg.view import bfg_view
from repoze.bfg.chameleon_zpt import render_template_to_response
@bfg_view(name='my_view', request_method='POST', context=MyModel,
permission='read')
def my_view(request):
return {'a':1}
.. code-block-teardown::
del sys.modules['models']
Only the code-block would show up. Actually being a code-block would be
helpful, too, so we could use the other features of code-blocks, like line
numbers. Or something.
- C
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 6:43 PM, Chris McDonough chr...@plope.com wrote:
Yeah. I haven't thought about this much, so it might be bollocks, but I
think something like this is what I'm after:
.. code-block-setup::
import sys
from somepackage.testing import DummyModule
sys.modules['models'] = DummyModule()
.. code-block:: python
:linenos:
from models import MyModel
from repoze.bfg.view import bfg_view
from repoze.bfg.chameleon_zpt import render_template_to_response
@bfg_view(name='my_view', request_method='POST', context=MyModel,
permission='read')
def my_view(request):
return {'a':1}
.. code-block-teardown::
del sys.modules['models']
Only the code-block would show up. Actually being a code-block would be
helpful, too, so we could use the other features of code-blocks, like line
numbers. Or something.
If you replace .. code-block-setup:: and .. code-block-teardown::
with .. invisible-code-block:: python you can do that with Manuel now
(http://packages.python.org/manuel/#invisible-code-blocks).
--
Benji York
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: a proposed solution
I agree and support Martijn's strategy. There are *many* Zope 3 users who are not visible on this discussion. For example, these CMS are based on Zope 3, as you can find the word on the page. http://z3ext.net/news/z3ext-1_0_0-released/ https://makunouchi.jp/products Not only them, but more Zope 3 based systems exist which are not exposed on internet. I think ZTK community needs to think about them. In other words, Some directions should be provided to them when ZTK 1.0 gets released. Probably, many Zope 3 users are not participating community nor subscribing this mailing list. But developers who are developing *foundation* software need to consider *big* world beyond directly visible scope. I am not a programmer, but I have translated philikon's web component development book. http://www.springer.jp/978-4-431-10040-9 Takeshi Yamamoto On Jan 4, 2010, at 5:51 AM, Martijn Faassen wrote: I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] patterns for using sphinx with the Zope Toolkit?
Martijn Faassen wrote:
Martin Aspeli wrote:
[snip]
We've had good success with
http://pypi.python.org/pypi/collective.recipe.sphinxbuilder
I'm having trouble with this. I'm trying to set up a narrative_docs
directory in a package but:
* the documentation on collective.recipe.sphinxbuilder pypi talks about
a bin/sphinxbuilder script. That simply isn't there (the sphinx-build
and sphinx-quickstart commands are). Ah, I see it is named after my
section. The documentation didn't say that.
:)
* I'm supposed to run sphinx-quickstart by hand and answer a few
questions and choose docs-source as your source folder. I'd like to
tell about my source folder, but instead it asks me for a root path for
the documentation. I cannot directly control the source path at all,
only whether it is the root path or whether it's in root_path/source.
I can't really remember what answers we gave, but I know we ran it once
and from then on we've been able to do ./bin/sphinx to rebuild from reST
sources.
The quickstart thing is only necessary when you start a new project, so
you should only use it once per package.
* I'd prefer it if I ended up with a sphinx quickstart script that got
preconfigured with the choices I made in buildout anyway, or perhaps
even run quickstart itself when necessary (but a manual step here is
okay and perhaps the sanest)
There's also a z3c.recipe.sphinxdoc recipe. This seems to be geared
towards producing sphinx documentation from doctests within a Python
package. I think to encourage narrative documentation I'd like to
separate this documentation from the source tree (though I *would* like
to have the *option* to use doc tests).
Yeah, I saw that one, but had the same conclusion.
* Do I need to answer 'y' or 'no' to the 'Create Makefile' question and
a windows command file?
This is definitely frustrating. :) I want to document something about
this so that people have more guidance and that our ZTK packages have a
similar documentation structure,...
This is what we have in our (project) buildout:
[sphinx]
recipe = collective.recipe.sphinxbuilder
source = ${buildout:directory}/docs/source
build = ${buildout:directory}/docs/output
eggs =
${eggs:main}
repoze.sphinx.autointerface
${eggs:main} is a list of eggs that make up our project's main
dependencies. We include them so that we can get the automatically
generated documentation to work.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] shrinking the ZTK: what happened (my perspective)
Martijn Faassen wrote: Hi there, This is a summary of the previous discussions for those who weren't paying attention last week and don't want to read a huge thread coming back from vacations. I'm talking about you in particular, other steering group members. I'll spread it out over multiple short mails. So what happened? Hanno reduced the ZTK to a set of just zope.* packages. He removed the zope.app packages from the ZTK. I was happy with losing zope.app, but not the way the zope.app packages were just unceremoniously removed from the ZTK without discussion. I didn't like the way that was done, so I reverted Hanno's change and added the packages back to the ZTK trunk. I objected because of backwards compatibility concerns. Version information was being lost that was being maintained before. This information would be useful in both upgrading Zope 3 and Grok applications to the ZTK. (and I thought Zope 2 too at the time, but it is less of an issue there) People responded in various ways: * the ZTK isn't released yet and a discontinuity so there are no backwards compatibility concerns we need to care about. * people maintaining Zope 3 or Grok applications, or the developers of these frameworks, should figure this out for themselves. I responded that if the ZTK wants users it should help people cross the gap to it. That the ZTK has some responsibility to the transition from the past. Nobody seemed to feel that these arguments weighed very heavily. Since I'm writing this summary, I'm of course still right. :) Let me put that in other words: I believe have a legitimate concern that we could have solved pretty easily if we all weren't too busy trying to make points and being disgruntled. +1 - I think concerns for backwards compatibility need to go beyond purely academic questions of what was released with what explicit or implicit promises, and consider what code is actually used in the wild. A lot of people are using zope.app.* (in Plone for one). A lot of people need good KGS' to do *anything* and can't resolve their own dependency conflicts easily. A lot of people look to ZTK as the way forward for a sane, stable set of Zope packages to depend on. Those three groups of people overlap quite significantly. Maybe we never made them any strong promises, but that doesn't mean we shouldn't try to make their lives easier. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] how to help Martijn (how can we have better discussions?)
Martijn Faassen wrote: What lowered the quality of this discussion? I think it is because various people became quite upset and annoyed. That's because I reverted Hanno's changes to the ZTK trunk. I shouldn't have done that just like that, but I needed the subsequent discussion to come up with a better solution. I think you and Hanno were probably both equally wrong. :-) - Hanno's work probably should've been in a branch with a post here asking to merge it - You probably shouldn't have reverted his work so quickly. Few things irk developers like having their work (or others' work they care about) reverted. In the turmoil, my attempts to formulate a solution that would satisfy everybody's concerns fairly well seemed to have been overlooked a little bit. Instead we focused a lot of time on discussing bits we ironically enough actually more or less agreed about, such as the role of the ZTK. Nobody seemed to quite notice that I'm in fact in favor of a smaller ZTK, even though I said so repeatedly. That's because I'm *also* in favor of maintaining the zopeapp bits a while longer and not just throwing those away. I want an exit strategy for those bits. A transition strategy. That is a legitimate topic for this mailing list at the very least. +1 Instead, we had endless debates about whether it was a legitimate concern for the ZTK maintainers. I'm of course still right that it is. I have wonderful and coherent reasons to support my position just like everybody else does who disagrees with me. It's not really very important anyway. We're here together on this list to work together beyond the ZTK itself. I think one problem is that we speak about abstract groups of people, the ZTK maintainers, or the Zope 3 maintainers and now The ZopeApp maintainers. These groups don't really exist in any cultural sense. They don't have an identity in the same way that, say, the Plone maintainers or the Grok maintainers (and possibly, the Zope 2 maintainers) do. It's hard for any one group to make their voice heard when no-one knows if they're part of that group or not. :) I think in general, it's more useful to talk about the Zope community until such time that these groups actually self-organise, if indeed they ever do. So how can we have better discussions? We can have better discussions by helping me. How can you help me? Of course it helps if you agree with me. I realize that's frequently infeasible, but I certainly wouldn't mind. :) :-p If you disagree with me, I'd like you to try to understand my concerns as much as you possibly can. In addition, try acknowledge my concerns as much as you possibly can without feeling you're lying. This works beter than just rejecting them. I think this goes for anyone, not just for you. How else can you help me? You can propose realistic solutions for how we as a community can take care of these concerns that I have. And still fulfill your concerns at the same time. Such solutions were entirely possible in this discussion. Constructive debating is an art I'm still learning, but I had the feeling people enjoyed the rest of the debate too much to be very constructive this time... Of course the way you'd help me is the way anybody would be helped in a discussion, as the discussion becomes more constructive. Again, I know as much to blame as anyone else. I helped spark it due to my revert and my continued insistence that I am right. The revert shouldn't have happened. But I didn't know that at the time as I hadn't had time to think yet either. I think there's another lesson here: reverts are the open source equivalent of swearing at someone. It may seem like a good idea at the time, but it is basically saying your work is not wanted here. It offends at an emotional level and means the discussion easily stops being factual. It's a lot better to ask the developer to do the revert himself, if needed. At least then he has a chance to make the point. So how else can you help me? Give me some space to think. I believe my concerns could have been easily taken care of if we'd stopped and talked for a little bit *before* drastic changes were checked in. So, you can help me by discussing things that you know are drastic changes before you do them. I think we normally have a policy of making invasive changes on a branch and then posting here with a proposal to merge it. That's not a bad thing. We need to acknowledge that most of the work that happens in Zope land these days is about building a shared infrastructure for a few more user-facing projects: Grok, BFG, Zope 2, Plone, and possibly full-stack Zope 3. That means that there are a lot of stakeholders who have quite a big stake in some of our changes. We can't just unilaterally make changes. On the other hand, I think we almost always agree on what needs to be done, and I think we almost always come to constructive and useful conclusions. It can just
Re: [Zope-dev] shrinking the ZTK: a proposed solution
Hi, So here's my proposed solution for the ZTK shrinking issue: The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since Zope 2 forked the ZTK in response and continued to make changes to their fork, I've tried to keep it in sync with the Zope 2 fork. I've created a new 'zopeapp' package that expands the ZTK with zope.app. packages in my sandbox. This extracts that information from the ZTK. Hopefully after we get some feedback from other steering group members (very silent indeed in the holiday period when all this happened) we can make these two projects the official one: a ZTK project and a zopeapp project. +1 I think we do need to start being a bit more explicit about who these people are, though, or (I think more reasonably, at least in the short term) acknowledge that really there's one community: the Zope one; and various *audiences*. Documenting that somewhere (and possibly letting people indicate their interest in one or more audiences and one or more sub-projects, like ZTK vs. ZopeApp) would at least help us make sure that we had all points of view represented. A few things I ask the ZTK maintainers: I ask the ZTK maintainers to have the same concern for the zope.app packages as for any other user of the ZTK: work to support zopeapp's compatibility with the ZTK. If the zopeapp maintainers have issues, listen to them seriously. I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people) I also strongly encourage the ZTK maintainers to consider the situation of backwards compatibility seriously. Help people transition from their code now to the ZTK. Helping everybody migrate to the ZTK smoothly increases the value of the ZTK itself. Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers. I also think we as ZTK maintainers should better consider the concerns of other users of the ZTK. In this case, Zope 2 had less of a concern for zope.app than Grok or Zope 3. I didn't even understand this until the debate was further along. The concerns of others should be considered as well instead of simply rejected. We usually can find ways to balance the concerns of everybody. To that end concerns (or lack thereof) should be clearly communicated and be listened to. +1 to all of that. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Announce] BlueBream: Script to setup a Zope project directory
Hi Alex, Thanks for the feedback. I will look into the bugs you pointed out. On Mon, Jan 4, 2010 at 12:38 AM, Alex Clark acl...@aclark.net wrote: [snip] Another obvious question (sorry ;-), why not just contribute to ZopeSkel (which is currently in need of some active contributors, IIRC)? I felt ZopeSkel scope is very large. ZopeSkel is a great project for its users. BlueBream is Prepare the way for born-again Zope 3. BlueBream could be a getting started story for Born-again Zope 3. If desired, it could adopt the project name as BlueBream itself. Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Announce] BlueBream: Script to setup a Zope project directory
On Mon, Jan 4, 2010 at 12:38 AM, Alex Clark acl...@aclark.net wrote: Also, there are a few installation issues (fixed by running `mkdir -p` by hand): http://pastie.org/765137 http://pastie.org/765140 On a closer look, this error puzzling me. The var and its sub-folders are already existing in the source. But when I run setuptools sdist command, its missing from the tar ball. I have these two options in my setup.py: packages=find_packages(src), include_package_data=True, Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
