Comments (23)
The question is what do we want to be werkzeug.contrib? Should it only contain wsgi related stuff or should it contain helpers for web development?
If it's the first one (only wsgi-related helpers) then werkzeug.contrib.cache and contrib.atom should go away.
Another question: is iterio even used widely, what was it's purpose? It depends on greenlet and seems to be the only part that does not even work without a external dependency.
from werkzeug.
iterio should go into a separate PyPI package. Maybe the same should be done for cache, not sure yet. The modules from contrib I use are securecookie and cache. I don't think I ever used anything else from there. We could do a poll and ask what people are using enough that it's worth having in Werkzeug itself.
Cache however lacks support for newer memcache adapters, so if it sticks, it needs an updated interface.
from werkzeug.
Cache is pretty well-maintained now, but i'd like to get it into a separate pkg anyway. The only module which really should stay is fixers
IMO.
from werkzeug.
I wonder if we should move even more modules into separate packages, even though they are directly relevant to Werkzeug.
An example would be werkzeug.urls
: A general-purpose backport of urllib.parse
is extremely useful outside of Werkzeug's context, and it'd be very useful to have potentially more maintainers on it who are otherwise not interested in using Flask or Werkzeug.
from werkzeug.
i like the idea, but it needs some preparation and thougts
from werkzeug.
I could be interested in helping out here, but would obviously need some decisions being made here. One idea would be extract some parts to external packages, i.e. werkzeug.contrib.cache
to werkzeug-cache
or some such, middlewares to werkzeug-middleware
, etc.
We could for instance include these packages as dependencies in Werkzeug for a while and alias them in their existing locations for backwards compatibility, while emitting deprecation warnings about their future removals.
from werkzeug.
sounds like a good plan to me, @mitsuhiko @untitaker do you agree?
in case the others agree i propose providing @asteinlein with a repo under pallets for werkzeug-cache as a starting point and using werkzeug_cache as potential module name
from werkzeug.
Agreed! Will set up a repo later.
IIRC somebody already forked Werkzeug's profiler middleware into a new package.
We should seek collaboration from that person.
On Fri, May 27, 2016 at 01:59:58AM -0700, Ronny Pfannschmidt wrote:
sounds like a good plan to me, @mitsuhiko @untitaker do you agree?
in case the others agree i propose providing @asteinlein with a repo under pallets for werkzeug-cache as a starting point and using werkzeug_cache as potential module name
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#4 (comment)
from werkzeug.
from werkzeug.
Middlewares will require more discussion, which ones to keep in Werkzeug and which not.
The things that IMO definetly can be factored out are:
- cache
- atom
- fixers
- profiler
from werkzeug.
Let's start with cache
: https://github.com/pallets/werkzeug-cache
@asteinlein I've added you as a collaborator to werkzeug-cache, @RonnyPfannschmidt you're a member anyway.
from werkzeug.
Oh, I forgot that werkzeug.locals
is a candidate as well!
from werkzeug.
werkzeug.contrib.wrappers
contains some interesting request/response mixins. At least ProtobufRequestMixin
should probably go. The ones we keep should move into werkzeug.wrappers
. I'm already doing this for JSONRequestMixin
. (It might be a good idea to split wrappers
into two moduels, request
and response
.)
from werkzeug.
+1 on these:
- move local into a repo
- move cache into a repo
- find a solution for contrib wrappers
-1 on urls
Two reasons for this: a) i don't want to start having tiny dependencies everywhere. This is a huge maintenance hurdle and I keep learning this over and over at Sentry. Secondly because it's not even an entirely correct implementation of URLs.
from werkzeug.
@mitsuhiko I was proposing urls
because I once needed something that behaves the same on both Py2 and Py3 and didn't want to depend on a WSGI library for that.
from werkzeug.
@untitaker why is the repo (https://github.com/pallets/werkzeug-cache) deleted?
from werkzeug.
@lepture i cannot remember but i think the transition was not properly coordinated, people still submitted PRs
from werkzeug.
@untitaker I'm closing issues related to cache. #1249
I'll make a separated repo in next week.
from werkzeug.
Created https://github.com/pallets/cachelib
from werkzeug.
I added cards for all the contrib
code to https://github.com/pallets/werkzeug/projects/2
from werkzeug.
I didn't add a card for werkzeug.local
because it's not in contrib
, although we may still want to extract it eventually.
from werkzeug.
Things I marked as "discuss, probably remove":
wrappers.RoutingArgsRequestMixin
- seems to be a spec that was never adopted, although it almost matches Flask, which setsRequest.view_args
during route matching.wrappers.ReverseSlashBehaviorRequestMixin
- not sure when this would be used, seems like other code in Werkzeug is handling leading and trailing slashesfixers.PathInfoFromRequestUriFix
- is this still a problem with Windows? Is CGI on Windows Apache something we need to keep a fixer for?fixers.HeaderRewriterFix
- not sure if this is worth maintaining. It's pretty straightforward for an app to implement exactly what they need, with more nuance than this gives. The examples (removing Date, adding X-Powered-By`) both seem to be bad practice (mandatory header, fingerprinting information).
If we're +/-0 on any of these, we should prefer adding a deprecation notice. If people report they're still using something, we can always reconsider the deprecation before 1.0.
from werkzeug.
Marking this for 0.15 to deprecate everything that needs to be. We can have a separate task to remove deprecated code for 1.0, which will include more than this.
from werkzeug.
Related Issues (20)
- `pyright` in strict mode errors when using `formparser.MultiPartParser.parse`
- MultiDict does not handle None values HOT 1
- Test regression with pytest-8.0.0: `tests/test_exceptions.py::test_response_body[RequestRedirect]` HOT 2
- Add "421 Misdirected Request" http exception
- Update runtime dependencies HOT 1
- Random "ssl.SSLEOFError: EOF occurred in violation of protocol" when handling HTTP 206 HOT 2
- OSError: [WinError 10038] An operation was attempted on something that is not a socket HOT 2
- `FileStorage.name` should be the filename HOT 2
- Use of Python 2 `print` statement in quickstart docs
- Handle AssertionError for fkask-socketio HOT 2
- BaseWSGIServer: throw exception on bind failure rather than calling sys.exit() HOT 4
- TLS connection not properly closed HOT 1
- Inaccurate Content-Range header in for partial content responses. HOT 1
- Test failures with pytest-xprocess-1.0.1 HOT 4
- Uploading a file of a specific size causes the server to hang up HOT 1
- bad arg-parse in python versions >= (3, 10) HOT 2
- XMPP: Post to PubSub HOT 5
- Several issues with CacheControl types HOT 1
- `TypeConversionDict.pop` could pop with type HOT 1
- Upgrade of Werkzeug from 2.2.3 to 2.3.0 resulting in api failure
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from werkzeug.