On 2011-03-21 12:29:13 -0700, Mike Orr said:
On Mon, Mar 21, 2011 at 11:08 AM, Alice Bevan–McGregor
<al...@gothcandy.com> wrote:
On 2011-03-20 23:23:02 -0700, Mike Orr said:
On Sun, Mar 20, 2011 at 8:12 PM, Joe Dallago
<jd.dall...@gmail.com> wrote:
This issue has been previously discussed, I just wanted to make sure
that everyone agrees. At the moment the docs refer to "paster
templates" and renderered templates(mako, chameleon, jinja) using the
same name. I propose that we change the official nomenclature used to
describe "paster templates" to "skeleton," and leave the word
"template" to describe rendered templates. Any objections? I will
start going through the docs as soon as I get the ok from everyone.
Yes. I already did that in the Akhet manual but I had to introduce it
with "template" and use "template" in the PyPI description for ppl who
might not recognize it. The sooner we can get away from "template"
completely, the better.
--
Mike Orr <sluggos...@gmail.com>
±0 — skeleton describes what it is less than, say, blueprint. A Linux
/etc/skel is static, for one. Blueprints often reference other blueprints,
too.
I like the word blueprint better than skeleton, actually. I would have
suggested it but you had already taken the name.
I don't think we can use your implementation classes directly, because
they make a several fundamental changes compared to
PasteDeploy/PasteScript that I don't think Pyramid is ready to commit
to at this point.
All PyPi-installable releases of Marrow packages (other than
marrow.util, but that will be remidied) feature 100% unit test
coverage, full documentation, and multiple real-world examples. The
only possible issue with the suite is the "bus factor", but garnering
additional contributors should help alleviate that. Alex Grönholm has
already been a huge help in updating TurboMail (marrow.mailer) during
the PyCon sprints.
Such as using alacarte, being another namespaced package, adding
several dependencies, etc.
marrow.blueprint relies on marrow.script for the command-line interface
(these are integrated in PasteScript), alacarte allows the trivial use
of any arbitrary templating engine instead of forcing a choice upon the
developer, and other than a minor issue with distribute and './setup.py
develop'ed namespace packages (which I talked to the distribute guys at
PyCon about), I fail to see the issue with namespaces. import this,
and all that.
Also note that the Marrow suite of packages feature extensive test
coverage, documentation, and are all extremely small. (Usually < 300
SLoC after comments, docstrings, and whitespace are removed.) In this
particular case, dependancies are actually a good thing and a sign of a
truly modular design. In theory it should be relatively simplistic to
write a PasteScript front-end to marrow.blueprint and make the
marrow.script/PasteScript dependancy conditional and auto-sensing.
I've heard your packages are also Python 3-only?
This is incorrect. All marrow.* packages are Python 2.6+ -and- 3.1+
compatible without source modification during installation a la 2to3.
2.6 as a minimum makes this surprisingly simple, but allowances can be
made for compatibility with earlier versions; the most difficult part
is the unicode_literal syntax and b'' string prefix.
I think what we'll probably do is make a new implementation of Paste*
but keep the features and API mostly the same, at least that's what a
few developers are working on. Would you mind if we use the term
"blueprint" in this "paster create" replacement?
Blueprint makes sense as the word to use and I have no complaints over
shared use, either. The goals of the software packages are the same --
create a directory structure populated with files generated from
strucutred on-disk templates. :)
Marrow is, itself, being written to replace Paste*, WebOb, and a few
other WSGI packages using a ground-up approach. Syntax-compatibility
wasn't a goal I considered too important; updating the concepts behind
the packages to meet current language capabilities, Python 3 support,
and simplicity were the primary goals.
Re-inventing the wheel isn't always a bad thing, especially if the end
result is a smoother ride. ;)
— Alice.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
