When I saw https://github.com/Pylons/pyramid_chameleon, I thought it's a
dependency of Pyramid, only to find that it's been integrated into Pyramid
itself. Why is it there?
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To view this discussio
On Sunday, January 20, 2013 3:34:05 PM UTC+2, Chris McDonough wrote:
> On Sun, 2013-01-20 at 00:32 -0800, Tshepang Lekhonkhobe wrote:
> > When I saw https://github.com/Pylons/pyramid_chameleon, I thought it's
> > a dependency of Pyramid, only to find that it's been int
entation reflects the current working state, I consider people
> visiting github repos as more advanced user looking at more than just
> stable stuff. If we decide to drop those projects from happening then yes
> we can remove them, not before.
>
> On Sunday, 20 January 2013 10:5
As an example, given this piece of doc:
"render(renderer_name, value, request=None, package=None)"
As explanation would start with:
"Using the renderer specified as ``renderer_name``...".
I think this can be misleading at first to readers, as it was to me, that
renderer_name is some special ty
Could we simply remove this? Does a user need to know which exact alpha (or
beta) release an API was added? I think such detail is a bit of overkill
for 'versionadded' Sphinx directives; it's better left in VCS history.
ok: added in 1.4b2
better: added in 1.4
--
You received this message becau
anyone?
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups
Paul
>
> On Monday, January 21, 2013 10:53:03 PM UTC-8, Tshepang Lekhonkhobe wrote:
>>
>> As an example, given this piece of doc:
>>
>> "render(renderer_name, value, request=None, package=None)"
>>
>> As explanation would start with:
>>
>&
On Fri, Feb 8, 2013 at 7:29 PM, Michael Merickel wrote:
> The URL format is /.-branch, with 1.4 as /latest the latest
> stable, and /master as master (in development).
* I find this misleading. I would expect "latest" or "dev" to refer to
"master", and 1.4 (latest stable release) be referred to a
ow, so unless we make a "stable" branch that
> we merge with "1.4-branch" every time we update, we make do with latest.
> Same issue with the major.minor -branch issue.
>
> If someone wants to add alias support to RTD, knock yourself out!
>
>
> On Fri, Feb 8, 20
The files in docs/api/ have the _foo_module directive at the top. This
allows one to hyperlink to pyramid.foo API documentation by using
:ref:`foo_module`. One can already simply do :mod:`pyramid.foo` for
the same effect (only not italicized, which am sure does not matter),
so me wonders why add th
I find the file overlong and messy. I would therefore like to get rid
of all commented-out unused options (those which just display a
default value). Is this acceptable?
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this gr
It is common practice to put licensing/copyright info at beginning of
files, but that info is missing on few of the files I looked at in
pyramid/ directory. Is it not an issue.
This question was prompted by my filing
https://github.com/Pylons/pyramid/pull/939, wondering if it's
necessary at all to
Why choose a non-commercial license[1]? This has the disadvantage of
disallowing, for example, Debian to distribute it[2], which would be
nice.
[1]: http://creativecommons.org/licenses/by-nc-sa/3.0/
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640780.
--
You received this message becaus
On Fri, Mar 22, 2013 at 10:32 PM, Chris McDonough wrote:
> On Fri, 2013-03-22 at 22:07 +0200, Tshepang Lekhonkhobe wrote:
>> Why choose a non-commercial license[1]? This has the disadvantage of
>> disallowing, for example, Debian to distribute it[2], which would be
>>
On Fri, Mar 22, 2013 at 10:44 PM, Steve Piercy
wrote:
> On 3/22/13 at 4:32 PM, chr...@plope.com (Chris McDonough) pronounced:
>
>
>> On Fri, 2013-03-22 at 22:07 +0200, Tshepang Lekhonkhobe wrote:
>>>
>>> Why choose a non-commercial license[1]? This has the dis
On Sat, Mar 23, 2013 at 12:59 AM, Jonathan Vanasco
wrote:
> I'd suggest these 2 strategies:
>
> 1. Dual-License the Docs as a choice between Current or the Perl
> Artistic license. The Artistic license is OSI & Debian approved, but
> neuters most commercial activities ( docs can be on retail CDs
On Sat, Mar 16, 2013 at 9:23 PM, Tshepang Lekhonkhobe
wrote:
>
> I find the file overlong and messy. I would therefore like to get rid
> of all commented-out unused options (those which just display a
> default value). Is this acceptable?
anyone?
--
You received this message bec
I'd say it better to stay there, as it provides inline documentation for
> settings that you might turn on.
>
> To clean it up, maybe split settings in two sections - configured and
> commented.
>
>
> On Fri, Mar 29, 2013 at 1:00 PM, Tshepang Lekhonkhobe
> wrote:
>
If you look at http://www.pylonsproject.org, you will notice there is
a tab named Tools, and all it points to is a list of pastebins. Seems
to me a forgotten corner, so I vote for removal.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsub
I feel these pages[1] are in the wrong place, that there should be
hyperlinks there instead. The content would therefore get moved to the
respective project's docs (i.e. FAQ , About, and Download). In fact,
Pyramid's About[2] partly duplicates some content seen in Pyramid
Intro[3].
[1]:
https://g
20 matches
Mail list logo
