I wanted to do it for a long time now, and when explaining my webob
decorators earlier today I decided I'd give it a go.
I'm not promoting it or suggesting anyone should use it. It's just
that Paste almost begs for a cleanup IMO so I felt like doing it.
I didn't :) I think what I'm doing is mostly in line with how you see
Paste's future (well, maybe except that I really don't like
PasteDeploy and remove all traces of it).
However I also want to rewrite pasteob.auth so it will use Contextual
which will have a number of benefits, but obviously it will have
little to do with paste.auth in the end.
I also wonder what's going on with WebError, I can't find a repository
for it. Is it just me or does it not exist?
Ever since seeing http://pythonpaste.org/future.html I've had some concerns.
One of the great attractions of Paste is one-stop shopping. The
included functionality might not be super-awesome but it's often
sufficient. Furthermore, please consider the effort the goes into
seperate packages - in every single environment I've ever worked in,
there has been a strict package policy and more packages simply
translates into more work - each package sometimes requires
justification and individual packages also translates into a great
deal more review, compatability testing, and interconnected
dependency.
One example of this is the extraction of paste.exceptions and
paste.evalexception into WebError. I like WebError but I'm curious why
an alternative approach cannot be discussed: why not take WebError and
put it back *in* to Paste? A ton of projects out there already rely
on Paste.
I *like* the idea of Paste as one-stop shopping.
I don't see the logic behind removing urlmap (surprisingly, this is
one of the most-used bits in my projects). paste.cascade I admit I
don't use much but it's simple and elegant.
paste.proxy also works for 90% of the cases out there.
paste.translogger does what it does perfectly well, and I don't see
the overlap there with other logging (debug logging vs. access
logging) - yes they both have "logging" in their name but that's about
where it ends.
The "To Deprecate" section I can't find too much fault with, and other
than paste.gzip and paste.session (a *simple* but not necessarily
awesome session component) the entire "Undecided" section could
probably go into "To Deprecate".
It seems to me that paste suffers from some of the same problems as
the standard library - enough of it works well enough and it's
sufficiently well-deployed that it has it's own inertia, and the
decision to throw it out (or much of it) seems easier than fixing it.
However, I feel that most of paste.core works well enough, despite
needing an "internal" clean up. I'd volunteer to do a bunch of that
cleanup, but splitting out paste core into a bunch of packages is not
the direction I'd favor.
Paste core has long been a wonderful addition to our community,
serving as a fantastic starting point for frameworks, an easy-to-use
(if somewhat occasionally opaque) library upon which people can
*learn* how to use wsgi and create new applications. I feel that by
splitting it paste is reduced in not just utility but attractiveness
as well.
Paste typified the batteries-included aspect of Python, even if it has
some warts. I say that we fix those issues.
Let me suggest perhaps a Paste 2.0 project which does not expand on
Paste's dependencies, does not split out too much stuff, but exists is
a cleanup and deprecation project. What I love about Paste is that
it's easy to get started with and when your app needs a "better"
session you can swap it out without much effort, but trying to find
out why your app works when you have a half-dozen dependencies can
hurt.
I'll note that I like using WebOb but requiring it seems a bit heavy.
--
Jon
Well, branching would require me to keep backwards compatibility, and
I made quite significant changes to all the code I carried over,
there's almost no code reused as-is. So if one takes PasteOb and other
projects that are mentioned on http://pythonpaste.org/future.html the
sum of those parts will cover almost everything Paste does. Because of
this I think I will not be using Paste itself in future projects.
PasteOb is only to be used in new code (or refactoring). Paste showed
that WSGI components can be useful and independent at the same time,
so PasteOb builds on that idea and some of the Paste code, but it's a
little different. Ian mentioned more than once that with Paste
"Integration of the components into a usable system is up to a
higher-level framework". PasteOb is intended to be used directly
without building up layers and layers of abstractions, for me that
means that APIs have to be something you can use in day-to-day work
and not feel dirty.
> > However I also want to rewrite pasteob.auth so it will use Contextual
> > which will have a number of benefits, but obviously it will have
> > little to do with paste.auth in the end.
> >
>
> This will be awesome. The auth code in paste is really nice in feature
> but it's horrible to debug.
BTW. Ian, may I post announcement about PasteOb milestones here in the future?
> > I also wonder what's going on with WebError, I can't find a repository
> > for it. Is it just me or does it not exist?
> >
>
>
> It's now maintained by the pylons folks http://bitbucket.org/bbangert/weberror/
Thanks. It would be nice to have a link to that repo from pypi page.
--
Best Regards,
Sergey Schetinin
http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter