On Tue, 2011-08-30 at 19:51 -0700, cd34 wrote:
> pyramid_registration does pretty much what Apex does - or appears that
> it will. Apex is just auth + registration on top of pyramid. CSRF and
> Flash messages were added into it because CSRF should be included in
> any front-facing webapp and Flash messages just made it easier to
> communicate events with a user when they signed in, registered or
> their password was invalid. Supporting i18n should be done for any app
> developed in the 21st century.
>
> Same with Pyramid_openid - which is just authentication with Pyramid
> using OAuth2 as a provider.
>
> At what point does a toolkit become an application? You can't do
> anything with Apex except auth and registration. You can't deploy Apex
> as an application - the app would do nothing but allow someone to
> register and sign in. This is similar to Akhet which is a layer on
> Pyramid to give developers a more pylons-like environment. Kotti does
> have CMS features and by definition appears to be an application or
> framework that uses Pyramid as a base which would be ineligible.
>
> I imagine someone new to Pyramid may not find Kotti, or, may not make
> the association that it has quite a few CMS components available and
> ready for a Pyramid app. While you may not want to endorse external
> apps or show preferences, I think it benefits the communities on
> either side.
>
> I'm not really that concerned about it for Apex, but, having an easy
> to find set of extensions and apps should raise awareness for pyramid
> - if that is a goal.
>
So rather than reply to that in context, I'll list some of the problems
I've had in the past with software branding. I've already made these
mistakes at least twice. I'm really skittish about making them again.
Zope began life as a Python web framework/application server. Its own
scope was big, but it had a single definition in, say, early 2001 or so:
the set of files that shipped in its tarball.
Over time, the term "Zope" (out of developer convenience; naming is
hard) was used in the package names of things unrelated to
zope-the-web-framework. For example, there exist packages which are
perfectly useful independent of zope-the-web-framework:
"zope.sqlalchemy", "zope.testing", "the Zope Object Database (ZODB)",
"zope.sendmail", "zope.component", "zope.pagetemplate".... anyway, you
get the picture.. there's a lot of them; probably dozens of them.
They're all quite good; they're well tested and reasonably well
documented.
So what's the problem with that? There are actually 2 problems.
The first problem is that the "zope" brand became more and more
meaningless over time as the word "zope" became used in unrelated
software distribution names. Eventually, it reached a point where the
name "zope" in a package began to signify to its development community
"a package produced by people who also created Zope-the-web-framework"
as opposed to its original definition. But people not involved in
day-to-day development work still understood it to mean
"Zope-the-web-framework". As the stock of the Zope brand dropped
between 2002 and 2007 or so, so did the stock of these otherwise
independently useful and unrelated pieces; no amount of explanation
could adequately rescue them branding-wise. So people are still busy
recreating stuff that has been around forever in the Zope world only
because those things have been "tainted" with the Zope brand, as opposed
to having any particular technical flaw. The authors of those packages
lost, and the Python community also lost.
The second problem is actually the same problem but in reverse. Lots of
people in the Zope community would use "zope.foo" as a package name
(often, for the same reasons you mention above; to promote the brand, to
try to guide people along a search path, etc). Unfortunately, lots of
these packages just weren't very good: they didn't have good docs, in
particular (cultural thing), and some just solved problems that people
didn't actually have. And people noticed this. Just as the Zope brand
dragged down the stock of otherwise great packages named "zope.foo",
having undocumented, complex software named "zope.foo" helped drag the
stock of the Zope brand down.
In 2005 or so, I made the same mistake with the "repoze" brand; over
time it came to be meaningless in the same way that Zope became
meaningless for all the same reasons, and questionable software was
introduced as "repoze" software that dragged down the brand.
So with that as context, and with the scars still fresh, my thoughts are
these:
- there should be an unambigous way to decide whether something should
have "pyramid" in its name; it should not be a choice made out of
developer convenience or lack of imagination.
- packages with "pyramid" in their names should either be gauged to
have little negative impact on the larger pyramid brand or should
be held to some set of testing / documentation standards commensurate
with the core framework.
- packages which are concerned about the stock of *their* brand
being dragged down by a loss in the stock of the "pyramid" brand
should not hook themselves up to the Pyramid brand to start with.
Currently the strategy is:
- do not impose any particular quality control standards on things named
"pyramid_foo", but try to reduce the scope of the damage of things
named "pyramid_foo" that are poorly tested or documented by suggesting
that things named "pyramid_foo" be only pure add-ons rather than
applications or frameworks. Add-ons usually have a rather
limited scope and therefore have less chance of really damaging
things, while applications ("things with a ui") and frameworks
("things with a large API or alternate set of development opinions")
have a better chance at damaging the brand if executed poorly.
- Encourage people who want their software to be "officially recognized"
(e.g. be mentioned on
https://docs.pylonsproject.org/docs/pyramid.html#pyramid-add-on-documentation
and https://docs.pylonsproject.org/docs/libraries.html )to adhere to a
set of standards
(https://docs.pylonsproject.org/community/addons-devenvs.html ), and
work with them to de-subjectivize the requirements for addition there
as time goes by and more people want to contribute.
- Some projects are likely to grow over time, and reach a point where
their association with Pyramid is more incidental than meaningful
to an end user (e.g. Plone uses Zope, but Plone users don't really
care much about Zope). Try to identify these projects early and
encourage that they have a brand of their own, so as to not confuse
folks about what "pyramid" actually means.
As far as Apex itself is concerned, as I mentioned before, I don't
really have much of a problem calling it pyramid_apex; it's sort of an
inbetween thing. I suggested removing pyramid from the name mostly out
of conservatism. It does have UI, but it's sort of just an add-on,
and.. well.. this is why we need more work coming up with unambiguous
guidelines about what should have "pyramid" in it and what should not.
I don't know the answer.
As far as Kotti is concerned, I'm happy that Daniel didn't name it
"pyramid_kotti". It's just an application that happens to use Pyramid
and it really has very little to do with Pyramid itself. Whether "we"
should be doing more work to promote it or not is a separate question
but I am happy with its naming.
As far as Akhet, we created the above "policies" while we were trying to
figure out where it should go and what it should be named. We may have
created the wrong policies, but if you take into account the reasoning,
I don't feel like I can suggest a much better set of them. I'm not
unhappy that akhet is not named "pyramid_akhet"; it has its own set of
quality control standards, its own documentation, its own bug tracker,
etc. It seems reasonable and we do promote it in our own docs, and
people do find it, so it appears to be working.
Folks have suggested some sort of "pyramidext" prefix for packages that
want to associate themselves with pyramid but don't want to necessarily
subject themselves to the above policies. I'm not really opposed to
this. I'm not really 100% clear what the goal would be, however.
- C
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
