Pyramid addons that are not part of the pyramid project
cd34
people find those projects becomes difficult without having pyramid
somewhere in the project name. If someone searches github or any of
the other repositories, the search function is somewhat inadequate in
finding projects without Pyramid in the proper name. Projects have no
way to easily signify that they are an addon, yet, are not part of the
project.
What I would suggest is a naming convention for pypi packages that are
related to pyramid, but, not endorsed. Perhaps something like
pyramid_ext_ or pyramid_app_. Django applications use the django.
prefix and there is little confusion as it is the expected naming
convention. I feel that the name Pyramid needs to be in the name
somewhere so people looking for apps and extensions that work with
pyramid are easily found.
It is a two way street - it makes it easier for projects using Pyramid
to be found, and, having projects with the Pyramid name in it will
validate the framework as having activity and an external development
community supporting it.
Chris McDonough
FWIW, people should be free to name things that are truly add-ons (like
mailers, debuggers, etc) "pyramid_foo", even if they're not part of the
Pylons Project.
I'd prefer, however, that things that are not add-ons but applications
and frameworks in their own right that happen to use Pyramid as a base
such as Groundhog, kufu_opinion, Akhet, and maybe Apex have a separate
name. For lack of a better word, I'm terming these things "development
environments".
We should probably also have a set of Trove classifiers for these things
for PyPI. FWIW, the "keywords" can be used to put "pyramid" in there so
it can be found on PyPI.
In any case, the distinction trying to be made isn't between "official"
and "non-official", it's between "add-on" and "an application or
framework that uses Pyramid as its base".
See https://docs.pylonsproject.org/community/addons-devenvs.html .
I'm happy to reconsider this, but it's what we came up with while trying
to figure out how to deal with naming Akhet a while back.
- C
cd34
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.
bika
Thus being able to find existing apps is a great advantage of a framework.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Sebastien Douche
> 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.
The next step could be to add an entry in the Trove Classifiers. It's
easy to show all packages with that (with a "dynamic list" on the web
site).
Ex with BFG: http://pypi.python.org/pypi?:action=browse&c=540
--
Sebastien Douche <sdo...@gmail.com>
Twitter : @sdouche
Blaise Laflamme
Chris McDonough
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
cd34
bitbucket, sourceforge or code.google searches. What does affect
github is quite interesting and they put weight in areas I wouldn't
have expected. However, if someone is looking for extensions or addons
to pyramid after page two or three, the results become wildly
inaccurate and do skip over projects that you would only find if you
knew it existed. As for using pypi for search, I would bet that a
large percentage of the new adopters looking for code to support
Pyramid probably aren't using pypi as their search resource. And there
are a few projects that use pyramid that don't have the proper trove
classifiers, so, you still miss packages.
Because of the way the repositories do word stemming, pyramidext would
have the same problem you have right now.
But, point taken.