First to clarify, neither SQLAlchemy nor zope.sqlalchemy are
Pylons projects, although they may be dependencies for using SQL
databases as a datasource in Pyramid.
https://github.com/sqlalchemy/sqlalchemy
https://github.com/zopefoundation/zope.sqlalchemy
We Pylons maintainers agree with much of what you state. We
have identified the top points of friction for contributors.
* Signing a CLA
* Licensing
We're actively working through how to improve these items,
including relicensing and how to do so. We've gone through a
couple of iterations with third parties and the Plone
Foundation, and are currently in discussion with the Python
Software Foundation. If you want details of this process (it's
boring and tedious), please let us know.
The process includes the ability to receive and disburse funds,
something that previously went through Gratipay where an
individual incurred tax liability. We are not going to do that
again. We have not applied for grants because the Pylons
Project is not a legal entity that can receive funds; it's made
of people. Agendaless is an option, but it would not be a
taxable event. The PSF offers a non-profit tax-deductible
option which is under consideration.
As part of the organizational process, we looked at the long
list of Pylons projects under our GitHub user. We've classified
them as core, community, and tomb (unmaintained). We're focused
on core (https://pylonsproject.org/projects.html).
GitHub has adopted a lot of features that we want to implement,
but lack the time. Those features include all the things that
can be placed in `.github/`. I would welcome any issues or PRs
that add missing files, either per repo or preferably globally
under the Pylons GitHub user. It would save a lot of
reinventing the wheel.
We have done a lot of work in Pyramid to reduce friction. That
includes documentation, cookiecutter, pytest, tox, Black,
flake8, isort, and Travis-CI, Appveyor, and RTD. There is
active work on the Pyramid 2.0 release (https://github.com/Pylons/pyramid/milestone/5).
Pyramid has three open issues on i18n
(https://github.com/Pylons/pyramid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+i18n),
all of which are purely documentation. But again it's a matter
of time of knowledgeable people to share their best practices
and documenting them. I would welcome someone mentoring me on
how to do i18n properly, and I would document the process.
Pyramid does not care which templating library you use, there is
no longer a default, and offers add-ons with bindings for Mako,
Jinja2, and Chameleon.
Pyramid does not care which form library you use, but just like
templates offers bindings for form libraries. The growing trend
is away from server-side form rendering libraries like Deform
and WTForms to front-end JavaScript libraries that call an API,
all of which Pyramid supports.
Finally if you have specific issues that we can address, please
let us know.
--steve
On 7/30/19 at 10:38 AM, [email protected] (Hynek Schlawack) pronounced:
Hi everyone,
I don’t think I’m breaking any news when I say that the
development in the Pyramid ecosystem has gone a bit down and
it’s especially exemplified by amount of SQLAlchemy warnings
I have to silence in my projects that seem to be unlikely to be
fixed (<https://twitter.com/laurencerowe/status/1156111287631273985>).
In the worst case this means that we’ll end up without
SQLAlchemy for our documented workflows soon. There also was
the problem that the i18n documentation was an incoherent
mixture of old and new tools but that’s been a while so I’m
not sure if it’s still true. Venusian is triggering
deprecation warnings too btw.
The problem of course is that the current maintenance burden is
carried by far too few people (thank you so much Michael, Bert,
and Steve!).
***
One thing we could do is to find a way to stop
using/advertising packages that have to be maintained by use
and push for those that we share with Flask that is doing much
better. WTForms instead of deform comes to mind, Jinja2 instead
of Chameleon, and waitress might also not be worth the time
Bert is putting into it (unless he’s enjoying it :)).
Basically cut our losses and focus the remaining energy where
it’s most worth it. I realize this is not a popular proposition.
***
My main point is a different though.
I have tried to look at the projects that are screaming for
attention and found them very daunting and alien so I suspect
I’m not the only one who looked at it and gave up.
I hope at least some of you might have seen my PyCon US talk
this year where I talk about friction in contribution: https://hynek.me/talks/python-foss/
My offer for you would be choose select projects that are
essential to write awesome Pyramid apps and pull them into 2019
whether they like it or not. I’m not gonna start though
unless we can agree on it happening and how – turns out my
copious free time is everything but. 😬 But I do care about
Pyramid and I want it to stay strong.
***
Finally, there’s also the fact that Pyramid is used by
PyPI/warehouse so I suspect that it should be possible to ask
the PSF for money to close the biggest current gaps? Any
freelancers maybe?
***
I know there’s absolutely nothing I can do from people
starting discussing my motivation (paragraph 1) and “dead
batteries” (paragraph 2) vs my offer (paragraph 3) but I’d
still love to get a somewhat focused discussion. Maybe split
your replies?
Cheers,
—h
------------------------
Steve Piercy, Eugene, OR
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/r480Ps-10126i-42F99BA844B545CF9DE076A5B5033421%40Steves-iMac.local.
